How to Choose and Learn a New Programming Language

They say you should learn a new programming language every year.  I don’t necessarily agree, but it’s happening this year for me with R.  Here are the steps I have found over the years to make it go smoothly. If you’re a perl, C++, or Java zealot, it’s been nice knowing you…

Why Learn a New Language?

You may disagree or have your own unrelated reasons, but addressing the why seems a necessary start for such a how post.  Here are the reasons I could think of:

1. You want to impress someone. Your present/future boss? Peers? Just padding your resume? This is not a very good reason. Maybe just stick with perl/C++/Java.
2. Pursue a new domain. E.g., I’m heading into R because it’s touted as the best for visualization and statistics, and even has some epidemiologic facilities I hope to make use of.
3. You want to expand your mind. Given your new learnings, you’ll be able to achieve better/faster results with your present favorite language. E.g., learning FP is sure to help you with many other languages.
4. You’re actually going to need to use the new language for real work. You need to work on some app written in it, or you think it will be the best tool for your next challenge.
5. Get connected to a new community. Maybe those relationships will lead to finding startup founders.
6. Have something new to write about. Not a great reason, but I suppose I’m guilty.
7. Feed the hype machine. Maybe you’ve just heard too much buzz about a language and have to know what everyone’s talking about.  This was why I explored Ruby!

There’s got to be more reasons.  What have been yours?

How Long Should it Take?

Depending on your background and the new language you’re targeting, you should plan to dedicate some significant time to learning it. This is ESR on his first run-in with Python:

Not that it took me very long to learn the feature set. I wrote a working, usable fetchmailconf, with GUI, in six working days, of which perhaps the equivalent of two days were spent learning Python itself.

Or you could side with Peter Norvig and devote 10 years to it:

…it takes about ten years to develop expertise in [a programming language].

Maybe Peter only knows perl*, in which case I’d heartily agree, and so would others. Personally, I think a typical competent programmer can pick up a well-designed language in a couple solid months of hands-on study, though this estimate may be off by a couple years.

How To Actually Learn It

We all have to learn a bunch of languages throughout our hacking careers. How do you go about picking up a new one? Get a book? Start hacking? Stare at some existing code? Those are all useful things to do, but I want to streamline the process and get to the best practices. Here’s the checklist I’ve come up with for effectively and efficiently learning a new programming language:

• Click around on the home site. Discover the documentation pages, FAQs, wiki, community, etc. You’ll be back here a lot.
• See what Wikipedia has to say about it. You should see some interesting history and learn about why it behaves and looks the way it does. Maybe you’ll even find something to add.
• Print out the Tutorial and work through it. Mark it up with colors. Type the snippets into your REPL. Change them.
• Read the FAQ. At least browse it so you know something about the common pitfalls.
  
• Read the style guide. If it doesn’t have one, figure out why.  Hopefully you can find editor settings that will enforce it.
• Get a book. Sometimes it takes a couple. With Perl you’ll need eight tomes, all of which will be witty, yet combinedly inconsistent. With Python you’ll need one. (some will argue which one that is, many are great).
• Avoid certain languages. If you can’t find a book that dedicates fewer than 100 pages to wholly describing the language core, then something is wrong with the language. C++ and perl are violators of this, and prime examples of languages to avoid in all capacities, at all costs. You will waste all your energy on learning and remembering their quirks, instead of focusing on problems to solve. I can’t believe some institutions (my undergrad!) have used these to teach OOP. I would go so far as to call their paradigm QOP, or “quirks-oriented programming”. (WOP — “warts-oriented programming” — isn’t undeservedly harsh, but maybe not PC.). They will damage your thinking process, waste years of your programming career, or destroy it altogether, and you will actually become less competent for having ingrained their quirks into your cognition.*
• Work through the examples in the book. Highlight and scribble all over it. If the book is more than 600 pages, then either the language is crufty or the book is poorly organized, and you might not want either.
• Start collecting miscellaneous pages from around the web and bookmark and tag them appropriately. Look for language luminaries that have created nice bookmark collections.
• Hang out on the IRC channel. That will be irc.freenode.net.  The traffic on some of these is overwhelming, but you can quickly get a feel for what are the tricky corners of the language.
• Find a local user group to meet people and get connected. You can even get a feel for the language by surveying the attendees. Watch for excessive drool! If a SIG doesn’t exist yet, then start one. If no one is interested in joining, move to a bigger town or find a new language, or try to associate with one online.
• Join the users (and announcements) mailing list. You’ll get to see lots of code written by others and see solutions to common problems.
• Watch some videos (Google tech talks) and slideshows.
• Play in the REPL. Get a better REPL if available (ipython). What, no REPL? Beanshell doesn’t count. Bye-bye, Java!
• Try the debugger. See if there are better ones.  Can you dive right into it from crashing code?
• Get the tool suite. Get familiar with the tools and understand why they’re necessary.
• Explore the vaults. Examples are Python’s PyPI (Cheeseshop), R’s CRAN, perl’s CPAN (though CPAN has similar issues to its books). Having extensive add-ons is a good language health indicator. Also note how difficult their packages are to install.
• Write a simple tool. That will season you in making use of important facilities. A good example is grep, which will exercise regexes, getopt (Erlang’s was hard to find), command line, strings, files, etc.
• Blog about your experience. Trying to describe your learnings to others will ensure that you understand what you’re talking about.  Do I?   Learn by teaching can be even more effective than learn by doing.
• Find the right interpreter/compiler. Some languages (Lisp) provide many.
• Install it, and its documentation.  apt-get install ... Not available in apt?  Then it’s too new, or you’re seriously bleeding edge, or it’s not viable.
• Figure out how to use the documentation systems. Manpages, info, –help, REPL-tab-completion, special tool (pydoc, Edoc, perldoc))
• Make sure your editor is equipped. What? it prescribes an IDE for you? Later, Smalltalk (Squeak)! Mess with your editor until it’s working as intended. Syntax highlighting, auto-completion, auto-indent, macros, etc.
• Learn a bit about its history. Why was the language created.  For what niche?  Are its strengths and weaknesses reflected in that history?
• Make sure it’s open. I shouldn”t go into this again, and I realize it’s a loaded statement, but I say avoid anything that doesn’t have an excessively open community and standards body around it.  I’m still teetering on the Flex (Adobe) fence, but anything that Microsoft has had its hands in developing is simply poisonous.
• Compare to a language you know.  What’s it most similar to?
• Take a class. This is often not necessary, but if you’ve got some college nearby they may offer something helpful.
• Get certified. Some languages have (silly) certifications.  The main benefit of them is that there is training material built around them that help you focus on what someone thinks are the important pieces of the language.  Doing this with Java helped my focus quite a bit (though I’ve since left the language behind).
• Watch/shadow a pro. This can be the absolute fastest way to see what to do, or what not to do.  Careful that you choose the right pro.
• Study the idioms and quirks. All languages have some quirks, even Python.  It’s best to know about them early.
• Find and explore a project source base that is known to be well-written. Dive into the code.  Try making some changes.

I’m not suggesting you need to do all these things for every language you explore.  This list could even serve as an evaluation for a new language you’re just considering.

Bonus: Go Deep

If you’d like to move on to the next prescribed level, here are some bonus activities:

• Find a bug in a library, and submit it to the BTS.
• Fix a bug and submit a patch.
• Understand how to mark up your code for document auto-generation.  Write a manpage/vignette.
• Check out the source using the VCS and build the compiler/interpreter yourself. If this is hard, you might consider if your apps to-be-written in this language can ever be deployed.  (Huge language bonus if they’ve got it together enough to be using a DVCS.)
• Try your app on multiple OSs. If you can get it to work on Linux, Mac, and Windows (at least Cygwin), you’re probably safe. Even a web app should have some portability since you never know what future co-developers might think they need to do.
• Start or join a real project.
• Make use of shared memory or message passing or whatever concurrency facilities are provided. Measure the quality of the language by how long it takes to figure out how to do robust parallel programming. Erlang takes a week. If it’s years, like most, you may want to move on, or read the next item.
• Integrate with another language, particularly C.  If this is impossible, it’s probably a showstopper.  Compare to Python and R as benchmark examples.

If you can’t accomplish all these things with the new language you’re considering, just move on to the next. There are plenty to try!

Note that these are all great things to do when getting started with a new language. However, you probably don’t want to be hanging out on IRC or mailing lists forever, or writing excessive posts about your fascinating new learnings, or reading too many books. I’ve fallen into all those traps.  The best advice I can give you (and myself) is to get those hands dirty!

What other things do you do to get comfortable with a new language?

* Notes: [1] Peter is actually pretty bright, and I was joking about perl. I sat on the floor right next to him last year at Startup School, without realizing who he was until he excused himself to give the next talk. [2] Wow, Stevey; that second glass certainly does get the juices flowing!

Tags: languages, optimization, qop