Learning 12 new programming languages in 12 months

However, in the article, Norvig himself points out the worthiness of learning several languages, and doesn't claim that you have to get on a ten year treadmill for any individual one, or even a subset. My impression was that Norvig was really targeting the people for whom whatever-language-in-a-fortnight-and-a-half would be their first exposure to programming at all.

As you gain more languages, provided you are judicious in choosing, so shall your learning of each of those languages be more rapid than the prior.

Does a month per language seem a bit rapid? Yeah, it kind of does, depending on the time spent in study and tooling. The pragmatic programmer guys suggest learning a new language every year; that seems wholly attainable. In reality, the author studied a language to what he considered a sufficient level in a quarter. That also doesn't seem that unreasonable, depending on the level of mastery desired. Could be that both perspectives have more than a grain of truth.

I ended up doing something similar to what this author tried to do starting in my sophomore year in college (although I didn't have any particular goal in mind when I started). Over the course of about a year and a half, through some combination of classes and my own projects, I programmed Standard ML, Prolog, Haskell, PHP, Ruby, JavaScript, x86 Assembly, Scala, SuperCollider, and Scheme for the first time. At that point, all I really knew were Java and Python.

I think it was an immensely useful experience for several reasons. I've now had some exposure to most/all of the major programming paradigms (and some less common ones too). A month is enough time to begin to get a feel for a language and its idioms, and being able to think and solve problems in different ways will make you a much better programmer even if you do end up working mostly in one or two languages.

Learning how to learn a programming language quickly is also an exceptionally useful skill. New languages don't scare me any more--I can usually learn enough to start hacking on something in a couple of hours, and enough to not be writing completely horrible code in a couple of days. And it's now very rare that I sit down to read a piece of code and can't figure out what's happening because I'm not familiar with the language, which is very helpful when I need to work on something I've never seen before.

That all said, there's a reason I didn't continue doing that indefinitely. Learning one or two languages really well is also very important.

Trying Prolog, Erlang, Haskell and Scala in the space of 4 months while trying to solve simple problems (Project Euler comes to mind) should allow one to find a language approach that works. Object-oriented, lazy functional, concurrent or logical, one of those might stick. And if not, there's Lua, Ruby, Groovy, C#, Scheme, Perl6, Python3, Forth, C++, Brainfuck, ...

Each language has a core idea or two that could fit someone's personality. Then, the next year could be spent learning that language in-depth, as you mention. Finally, build upon that experience and re-evaluate the orignal list of languages; JavaScript looks better after Lua, Haskell is Scheme with Prolog-like pattern matching and a generic type system like an advanced C++, Forth and Brainfuck are about a simplicity even beyond Scheme's, etc.

For example using std::<pair> more after spending time with Common Lisp.

Also it made me realized that certain building blocks, patterns, etc. are not that great when looked through a different view.

For example the "factory" pattern is needed in C++, because objects can be allocated on the stack... Wait... what?

Well, because C++ allows allocation of objects on the stack, obviously one cannot think in it, as if "new" would've returned object with different size than the one declared. e.g. "new SomeClass()" is known by the compiler how much space would take, hence "SomeClass someObject;" is known in advance and can be allocated on the stack. Cool, isn't.... Actually not so cool - because of that you can't return proxied objects, hidden implementation, etc... Hence you need factory - instead of "new SomeClass" -> CreateSomeClass() function that might return object of different size... Where I got aware of this - by spending some time with Objective C and it's objects.

Then comes the holly OOP, especially the C++ way - but then one discovers lua, javascript... Or Common Lisp... and understands - "protected", "private" are not that important, and the GOF patterns are not that needed.

Okay, so you go back at your work to code in C++, and just take it easier, because you have realized there is no point going hard-core and doing it the C++ way all the time. Hell it's even okay to have this macro called "HASHED( "SomeGameResource", 0x123123 )" that... gets preprocessed by external tool, that replaces 0x123123 with the hash code of "SomeGameResource" and puts it back in the source code.

#ifdef DEBUG

#define HASHED(s,c) hashed(s) // e.g. call function in debug to return the hash-code

#else

#define HASHED(s,c) c // replaced with the precalculated value

#endif

Now try doing that with templates.... But my point is - there is no need - just use an external tool that does it for you. Inform your programmers that if they want to change HASHED("BlahBlah", 0x123123) to HASHED("BlahBlah2", 0x123123) then they have to run it through a tool (or have such step), or just make them use the debug version. Or change the language... Joke! You are doing this for the Nintendo DS - "C/C++" is the only viable option for large project.