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!

Here are some great things I’ve discovered about R:

• Functional. Although I’ve dabbled in Erlang, Haskell, and ML, and grown towards using Python in various functional ways (Mertz, AMK), I can’t say I’m fluent in any sanctioned functional language (okay, I just added R to that list, but it should have been there: “R’s functional parts come from Scheme.”)  I want to continue “breaking my brain in useful and creative ways”, and R fits the bill for completing this repertory need (I’ll probably head back to Haskell if/when a strong need for concurrency arises).
• Statistics and data analysis. The Numerati and other sources say statisticians rule the world.  My eyes have been opened and I believe they’re right, so I’m working back my math chops.  It would appear that R’s statistics packages are more expansive than Python’s, and more is built into the language itself.
• Mathematical learning tool. It’s been a decade since I finished that math degree, but now the investment is finally paying off… I, uh, hypothesize.  I’ll blame the hiatus on not having found very interesting work to do until now — another reason to be self-employed, and why I’m loving life this year.  Anyway, I’m already getting re-versed in stats just by starting to use the language.  It’s looking like playing with R is a much better way to learn statistics than muddling through textbooks and paper-based homework.
• Graphical. Don’t know where to start.  There are so many graphical tools for R it is mind-numbing.  I’m starting to look at RGgobi, but there are lots of others to get acquainted with, including what’s built in.  I’ve worked through a couple graphical tutorials, and they seem to just magically pop up amazing graphs without having installed anything.  Try: > demo('graphics') Notice how few lines of code are doing all that. Wow!
• Geospatial. I’ve got a need to be plotting data on maps in a variety of formats.  I’ve found a lot of ways to do this, but R seems to be the lightest, and very capable.
• High-level. Everything is a data structure.  Operations applied to variables are done across the whole set with no loops or treatment of individual items.  The syntax appears to be a bit richer (higher level, more sugar) than found in Python.
• I/O. R seamlessly slurps table-oriented text files for processing.  Output is also automatically formatted in nice text tables.  A mini-book (PDF) describes this and much more.  My next learning task is to start interfacing with PostgreSQL.
• Kind of Python-like. I’ve started outlining another article that I hope to actually write someday called “R For Python Programmers” (since I can’t find such a guide).  Isn’t Python the gold standard to which great books make comparisons these days?  I won’t duplicate that here, but simply say that I can’t believe how comfortable the syntax feels coming from Python nativity.  And R appears to integrate very well with Python (this probably being the more important point).
• Best REPL evar! I start evaluating any language simply by firing up its REPL and comparing its facilities to those of IPython.  R’s REPL is on par with it (readline editing with vim-mode support, tab completion for everything, extensive help), and even has some extra niceties; e.g., function parameter tab-completion.  While getting started, note that the help system uses ? and ?? prefixes instead of IPython’s suffix notation.  IOW, use ?topic instead of topic? I’m getting the impression that a common workflow is spending lots of time in the REPL working with files and graphics.  This is probably the killer feature that enables me to quickly get up to speed.
• Documentation. The pages aren’t pretty, but there is a mass of info on the R site.  And AFAICT R is the foremost language used in recent Statistics textbooks.  There’s also a free 100-page (a good length, compare to Python Tutorial) intro book.  It’s horrible for non-programmers, and less than perfect for non-statisticians, but will get you familiar with some language features.  Appendix A offers a nice REPL walk-thru of language features.  I can’t find any Python books with much treatment of numerics, except for this one which seems to touch on some but shares space with language basics.
• CRAN. Incredibly diverse libraries (list of packages) for statistics, graphics, and even Epidemiology (probably overkill for my present needs).
• Mature and well-designed. R has been growing as the de facto FOSS statistical/graphical language for over a decade (inception in 1993, in the golden age).  It has grown up from the learnings of its ancestor S (shouldn’t R then be T??; I guess similar to C->B->A progression), which came onto the scene circa 1976 (a good year .
• Widely used. A survey of university statistics courses and Public Health curricula show R as a prevalent tool; e.g., UC Berkeley and Iowa State.
• UNIX-friendly. I was humored to see that R is more apt to borrow names from UNIX commands than from other languages.  The commands for managing a namespace are rm and ls — easy for me to remember.   And I’m glad to see it has good roots.
• Trivial Ubuntu installation. Try this: apt-get install r-recommended r-cran-<tab><tab>
• Script-friendly. Rscript enables R to act as a scripting language.
• PDX-visualization group. This month we’re starting up a group to discuss visualization technology/advances, and R will be the primary language under discussion.  My statistician friend, Ed, won’t stop talking about R, and he’s someone I’ve come to listen intently to.

It’s a bit early to be writing an article on a language I haven’t done much with yet.  But I had to explore what’s pushing me towards R.  Looks pretty compelling now, so I’m very close to diving in (actually using it in a project).  I’ve sprinkled a number of resources throughout this post which I hope will be helpful for newcomers to R (including myself).  I should also mention that the best articles I’ve seen on introducing R are by David Mertz (a very capable Pythonista): Statistical Programming with R, Part I and Part II.

I can’t ignore what’s been growing out of  Scipy, especially the maps.  And matplotlib’s gallery is incredible (and I have some of them working).  The above items are all great features of R, but if I can accomplish them nearly as well in Python I probably shouldn’t invest too much into R.  At this point it does appear that R offers some facilities beyond Python.  Have you worked with both Python and R and found compelling reasons to prefer R?  For which types of tasks?

My pain points with Python today are in analyzing query data (ad hoc in loops and heuristics), and creating a bunch of different formats to send to various third-party visualizations.  My analysis is going to need to get more sophisticated, and I’d like to be able to look at data visually quickly with less overhead.

I’m probably overstating the investment required in getting up and running with R; it’s supposed to be easy to pick up.  I’d really like to get to being comfortable with applying non-trivial statistics, which means working through some R books.  I’ve made it this far (and now so have you), so I’m going for it, hoping it will be a pretty quick learn.  Please feel free to share your experiences with learning and using R!

As you can see, these fit into a surprisingly small time window, which I’ll call the Golden Age.** I wanted to make it a round decade, but had to include Common Lisp.

• C++ (1983)
• Common Lisp (1984)
• Erlang (1986)
• Haskell (1987)
• Perl (1987)
• Tcl (1988)
• Fortran90 (1991)
• Python (1991)
• Lua (1993)
• Ruby (1993)
• Java (1995)
• Javascript (1995)
• PHP (1995)
• OCaml (1996)

What’s happened since 1996? Not much, besides refinement and extension. It would seem that it takes a decade or two for a language to really stabilize and see wide adoption.* But why did the innovation come to a screeching halt in 1996?

Here is a sampling of some languages that are sprouting up this decade. Maybe you’ve heard of some of them. But adopted one? Not likely.

• Scala
• Co-Array Fortran (features merging into Fortran)
• Unified Parallel C
• Fortress
• Chapel (vaporware targeted for 2010)
• X10 (secret vaporware)
• ZPL (vaporware)
• Titanium (not even in Wikipedia, just a Java dialect)

What do all these have in common? They’re trying to tackle concurrency. But none of these have significant momentum (arguably Scala has some). It’s probably at least 10 years before any of these get major traction. Will any of these take off the way the languages of the Golden Age have? Or will we just keep extending mostly imperative languages (OpenMP, Threading Building Blocks, vendor-specific compiler directives, etc). Where does FP fit into all this? Will the functional languages see a resurgence based on their natural fitness for concurrency? That’s my bet.

Which of the Golden Age languages have the cleanest concurrency models? I’ll be exploring that question in future posts.

Why do I care about this? I simply want to use the best language for the job (another future post). But most jobs these days are needing to scale to multiple cores/machines (the “free lunch is over” horse is dead; I won’t belabor that here). Everyone is talking about this unaddressed barrier to writing parallel apps effectively, but most programmers have no solution in mind. A language with clean concurrency support is essential so that applications will scale well, with little effort, and be easy to write, quickly and correctly. Let’s discover some and let everybody know.

Notes: Some of these dates were hard to locate and may be inaccurate. You may disagree with my unspecified definition of interesting. Scheme and Smalltalk are worthy of mention, but they make the window too big. I’ve omitted any language from Microsoft: they generally don’t last; those that do (VB, C#) are an uninteresting commercial niche; and they are always brown cows. I won’t try to prove the “decade for adoption” theory, but you can go search for data on when Java started to supplant C++; and Python/Ruby might be starting to do the same to Java (even though Java is the younger).

Related articles:

• Some programming language history
• Language history graph
• Some concurrent programming languages
• Do we need another parallel programming language?
• Cray, IBM, Sun weigh in on language
• Joe Armstrong on Software for a Concurrent World (video)