The second edition of How to Design Programs is not finished yet, but I recommend it anyway: http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html

Not bad: https://duckduckgo.com/traffic.html

Please read the article again, more carefully. I'm sure you just skimmed it while at work, that caused this misunderstanding.

It's not confusing. It would mean what you originally read only if there were a comma after "said".

s/confusing/easily misread and could probably be written more clearly/

I recognized them, nontheless, it would be nice to see the credits/licenses of the images.

Also, Happy Birthday Einstein!

Elemental mercury is very toxic, inhaling its vapor is dangerous.

https://en.wikipedia.org/wiki/Mercury_(element)#Toxicity_and...

It also takes the same approach as the posted article: reimplementing basic standard library functions. It's really enlightening.

I love the "reimplement the standard library" approach to learning a programming language.

When I learned C and Unix, the instructor had us reimplement libs like string.h and stdio.h, command line tools like date, ls and cut and then build tools like make.

It made me a much better C programmer.

C is a language I'd like to see make a reappearance in CS curricula. It's great that most programmers today don't have to deal with memory management and pointers, but I think a CS degree should leave the student with a basic grasp of the full stack of programming paradigms.

I think a nice approach would be to start off with a high-level, functional language like Haskell or Scheme, and then move down the ladder of abstraction in subsequent courses, culminating in a hardcore C (or maybe even assembly) course.

This is exactly what my school did. The first CS class was in Scheme, based on SICP. The next one was about data structures and based on Java. The last one was about computer architecture and used C followed by MIPS followed by designing a simple CPU with logic gates.

Overall, it's a pretty good system. The middle Java class was completely worthless and a big waste of time though; in hindsight, I should have skipped it. Also, while we learned a bunch of cool things in the SICP class, every single other class except for programming languages/compilers completely ignored it. Most retaught some of the same concepts, but poorly.

Also, apart from SICP, there aren't any undergraduate classes doing functional programming! What's up with that?

At least at my university, there's plenty of C and C++--even in places where it blatantly doesn't fit, like the other version of the compilers class. And far, far too much Python. And too little functional programming. Ah well, c'est la vie.

I would love a compilers course taught in ML (maybe OCaml?), and it's a possibility, but not before I graduate :(.

I graduated from the University of Chicago, and they have a handful of undergrad classes using functional languages. The intro comp sci courses were using Haskell for the honors class, and Racket for the non-honors version when I took it. The compilers course there is taught using ML, though the fact that UChicago has several faculty who work on the development and maintenance of Standard ML may have something to do with this.

Where are you studying? My undergrad (City College of New York) was mostly C++/Java with the exception of the PL course, which used Scheme. We also had an elective that taught x86 assembly.

I had to discover and learn Haskell on my own :)

I'm at Berkeley.

I also had to find Haskell on my own, but I think it worked out reasonably well in the end. The type theory/semantics class did use a bit of OCaml, but it took a while to get to it.

Also, I should add that--largely due to my own preferences--I've taken a disproportionate number of classes that do not really focus on programming at all. The aforementioned type theory/semantics course only had a token amount of programming, and three other CS classes had no programming at all. They were also some of the coolest and most fun. (After all, I can do programming on my well enough; theory is a bit harder.)

The C Programming Language takes a similar approach to exposition, and I think that's one of the reasons it's considered such a classic. It was certainly eye-opening for me when I first read it.

You can use this tutorial for the first step if you want to do it: Write Yourself a Scheme in 48 Hours by Jonathan Tang. http://jonathan.tang.name/files/scheme_in_48/tutorial/overvi...

It would be interesting to see how many languages you could nest before the interpreter becomes too slow to be of use.

I've always thought that this would be a better definition of what a "compiler" is vs what an "interpreter" is:

A compiler, if asked to "execute" itself a million times will generate code that is still reasonably fast.

An interpreter, if asked to "execute" itself a million times, will generate code that is a million times slower.

Theoretically, one could write an interpreter specifically for the purpose of nesting other interpreters, which would then (nearly) remove itself from memory as it transfers control to the second interpreter, but I know I'm not quite insane enough to start working on such a thing.

What would be interesting about it?

seeing how many languages you could nest before the interpreter becomes too slow to be of use.

I used a book "Remembering the Kanji" by James Heisig, which employs a special mnemonic technique, to learn to write 2000 Japanese kanji in three months, which was a leisurely pace (twenty-something a day). Many people did the same in a much shorter time, like 100 a day. It works beautifully. If you have problems learning those words, you are most probably either using the wrong technique, or using it incorrectly.

https://en.wikipedia.org/wiki/Remembering_the_Kanji

And it works! I have been using this method since 2009 and am quite comfortable with Kanji. When I started, I did 20 characters per day and was done in a little over 3 months. Though the real acquisition was in the years that follow.