These lists always seem a bit silly to me. It seems to be an attempt at being hip rather than a practical list. I thoroughly enjoy Haskell and Erlang, but I'm not sure they are languages anyone "should know". My list would be more like (pick one from each):

1. C

2. Python, perl, or ruby

3. Matlab or R

4. Common Lisp or Scheme

5. A fifth sufficiently different language, but with worthy concepts: Erlang, Haskell, O'caml, Prolog, Lua, Javascript, etc...

The choices in the first 4 don't matter too terribly much and the selection of a single language from #5 would largely be based on your own personal interests.

If you want to really be well versed in programming techniques, it's worth learning a statically-typed functional language -- Haskell, OCaml, SML, or similar. This will teach you techniques you won't commonly see anywhere else.

I wouldn't say you need to learn one of these, but I wouldn't say you need to know Matlab, or Lisp/Scheme either. Just that learning different programming styles will make you a better programmer. Prolog and Erlang reputedly have this property as well, but they're still in my to-learn queue, so I can't speak first hand about them.

Also, unless you never plan on going near the web, JavaScript is pretty much a necessity these days.

Prolog is disgusting. I wouldn't recommend it.

Your list seems just as "hip" as his list.

Why do you say that? Which part is hip? If my #5 were my list I could understand the comment, but my list is much more reasonable than the post. I use c, python, and matlab on a near daily basis for work so they are all quite practical. I think Scheme/Lisp are important to learn even if you'll never explicitly use them. The pl in 5 are useful depending on your domain, but I certainly wouldn't list these items as all being important to learn.

I would venture to say that Matlab/R are completely superfluous for most programmers. Few of us do hardcore number crunching, and for those few times it is necessary add-ons like NumPy take care of the problem. Someone considering your list would be better off dropping the Matlab/R choice and replacing it with Javascript.

I didn't think either list was "hip", I just meant that your list wasn't very different than his, except seemingly arbitrary substitutions based on what you happen to use.

He explicitly states: Note that I’m not necessarily advocating using any of these languages for a real project, but I believe that learning them will make you a better programmer in whatever language you do use.

I do think the original list was better, since Erlang, Haskell, and Prolog shouldn't be lumped together in the "different" category, Javascript could be considered part of the Python/Ruby/Perl class, and I question the usefulness of learning MATLAB unless you actually need it.

It isn't arbitrary at all. I think people should know a compiled language (procedural), a scripting language, a numerical computing language (w/ vectorized notation), and a functional language.

I think its completely excessive for the average programmer to know Haskell AND Erlang AND Prolog AND Smalltalk. Do you think people should know all of those? I see advantages to learning each, but I think my list would take the average person a bit further.

Agree with baha about the title. Just to clarify "Should you know" ... if you're pursuing an MS in Computer Science? Sure. If you're building a web startup? Not so much.

Practical lists of languages to know:

List 1: Java, Python, Lua, and C, or C++

List 2: Java, Perl, Ruby, C or C++.

If you know well 3 out of 5 of those languages from each list, it will be easy to find employment anywhere.

Other languages to know for fun: Ada, Lisp, Haskell, Smalltalk....

'English has no elegant way of expressing the difference between libre and gratis in Spanish' - 'Free as in beer' versus 'free as in speech' works for me. Also, shouldn't it be 'Which programming languages should you know?' if you're concerned with linguistic elegance? (To be fair, the title may have been written by an editor rather than the author, the rest of the piece is well-written and hard to disagree with.)

Did anyone actually read the article? He flat out says:

Note that I’m not necessarily advocating using any of these languages for a real project, but I believe that learning them will make you a better programmer in whatever language you do use.

This is not meant to be a list of practical languages everyone should be writing applications in, or pad their resumes with.

No programmers toolbox is complete without good knowledge of a simple, fast and dirty scripting language. In the past it would have been perl, nowadays it's more likely to be python or ruby.

That said, I really appreciate the benetfits of knowing at least how to read C, lisp, erlang and haskell. :P

Am I the only one that doesn't know a single one of those?

And frankly I don't care to learn any of them. I have never been turned down for a job because I didn't have Lisp skills.

In fact, I think I can count on my fingers the number of jobs that have required any of them...

I wish we could save links like we can on reddit. I want to use his list (and other suggestions from this thread) as future reference (I am currently learning Ansi Common Lisp)

Click in the upper right corner of this page where it says "Novash" and then look for the "saved" link. Everything you upvote is there.

I'm glad someone finally wrote a post on this topic.

There was a time where a sequence of assembly language instructions mapped directly to the processor's actions. But these days, assembly language instructions are cut up, reordered, and maybe interleaved with instructions from another thread; a conditional jump instruction that once had a constant cycle cost now depends on where that jump went the last dozen times and what is currently in cache.

What happened was that all the programs were being written in C, so the chip makers optimized their chips for C-generated assembly language. So now if you want to write fast assembly language, you need to write it more like a C compiler does -- which means in many cases that you might as well write it in C.

Any assembler programmer would know exactly what "secret shit" he's referring to. Microcode is highly processor-specific, lacks public documentation, and is loaded into the core as an opaque binary blob.