A personal programming language roadmap

Lately I’ve become increasingly sensitive to how little time I have left to learn new technologies. It’s not that I’m nearing death: I’m not, at least not by 21st century baseline human standards. It’s more a matter of the impossible and ever-expanding variety of tech that is out there to be learned. That, coupled with the limited time that that my work commitments and my family commitments leave me with; a spare few hours a week at most.

There are lots of reasons to learn new technologies.  Probably the most common reason is job-related necessity: land a C# gig, learn C#. I’m fortunate in that I don’t have to let work dictate what I learn at this point. I get to pick and choose how I will fill my limited research time based on other criteria.

I’ve always been a programming language hobbyist. I’ve always kept lists in my head, lists of languages that I “totally want to play around with one of these days”. Long lists. But it’s time to get realistic about what I can actually accomplish in the time I have.

Since time is precious, I don’t want to be haphazard. I don’t want to dabble. I have some vague ideas about how I’d like to contribute to the field of software development, and toward that end I want to maximize the utility of the time I spend in study.

So today I sat down, and took a look at my bookshelf. I thought about all the programming languages I have queued up in my mental “it would be fun to learn…” or “it would be fun to spend more time with…” lists. And I did some painful triage.

I came up with a list of programming languages I want to make a concerted to learn, because I think they will expand my skill and understanding in important ways. Ways that will hopefully equip me to explore some new directions I’ve been thinking about.

Here’s the list:

  • Smalltalk (in the form of Pharo) because I need to understand Alan Kay’s ideas better.
  • Elixir/Erlang, because I need to grok using agents and CSP in practice
  • Rust, because I need a better C++ for certain plans, and one finally exists.
  • Clojure, because I need to have hands-on experience with an industrial-strength lisp, persistent data structures, property testing, and the various asynchrony facilities it offers.
  • Elm, because I need to understand the reactive model better.
  • Emacs Lisp, because for greater efficiency I need to become more fluent in reworking my programming environment.
  • Io, because I need to understand how prototype-based objects influence program design.
  • Scheme, because I still want to work my way through SICP some day. Also, Chicken looks like fun.

This implicitly means there is a much longer list of languages that are off the table for now. It was tough letting go of some of these. A few notables include:

  • Node.js, because it offers nothing new.
  • Dart, TypeScript: Because as interesting as they are, they just aren’t relevant to what I’m doing.
  • Go, because I don’t need a better C.
  • Haskell: this hurts, because I badly want to do more with Haskell. But Haskell already expanded my brain once, and I need to expand my brain in different directions now.
  • Common Lisp: I really want to be able to say that I know Common Lisp. But realistically, modern lisp projects are going to be started in Clojure, not CL. The only reason I might go back on this is to understand CLOS better, so I can steal ideas from it.
  • Idris: there’s a future in stronger static analysis, but I don’t think it’s my future. I’m more interested in improving dynamic analysis.
  • Java 8: There’s nothing there for me that I don’t already have.
  • C# 6: A lot of neat ideas here, but none that will expand my horizons substantially.
  • C++11/14: Too little, too late, with too much baggage. Especially now that Rust is stable.
  • Scala: Mainly of interest from a Functional and Reactive point of view, and I think I have that covered between Clojure and Elm.
  • TCL: Part of me still wants to return to TCL and have some more fun with it. But it’s not going to move me forward in any meaningful way.
  • Modern Perl: Same discussion as TCL.
  • Python: a fine language, but too similar to Ruby to be worth re-acquainting myself at this point.
  • UPDATE: Factor, because unique as it is I haven’t seen anything to suggest that it will teach me things I need to know. I might be persuaded otherwise, however.
  • UPDATE: Julia, for the same reasons and with the same caveat as Factor.
  • UPDATE: Prolog, because I’m not solving that sort of problem. I may revisit this one.
  • UPDATE: Lua, because I don’t need to embed a super fast and simple scripting language in anything just now.

Of course, there’s a lot more to programming technology than just languages. But that’s a list for another day.

This is my roadmap, defined by some very particular and personal forces. It should not be your roadmap. But I thought I’d share it, as a source of ideas.

41 comments

    1. Well, it’s right there at the top of the list… 🙂

      I know a little Smalltalk, enough to read Smalltalk Best Practice Patterns without getting lost. But I need to build something real in it.

    1. It’s not relevant to any of my interests. It doesn’t bring anything unique from a PL design standpoint, and in general I’m not interested in platform/vendor-specific languages.

      1. Also, if you’re looking for a better C++, maybe look into D. (dlang.org)
        I’d say better C++ is definitely D, not Rust or nim. I once saw somebody categorized Rust as a ML.

        Also, if you’re looking into Elixir only because of CSP, i would recommend you Pony. (ponylang.org) Also since you’re already familiar with ruby. However, erlang world is still full of new ideas about agent based concurrency and robustness and error handling.

        Another language which I like very interesting to learn is Icon/Unicon.

        Also, have you took a serious look into perl6?

  1. I was surprised to hear that Erlang & Actors are even thought of as CSP. Go is definitely CSP, but taking a look at http://en.wikipedia.org/wiki/Communicating_sequential_processes#Comparison_with_the_Actor_Model , note that Erlang is different in all three aspects: Processes have identity, messaging is not rendezvous and there are no channels on which messaging occur. Also, anyone can read or write a Go channel. In Erlang, anyone can send to a process, but only that process will receive.

    If the bar to be considered a CSP is “concurrent processes that exchange messages”, that seems like an overload broad a low bar to pass.

  2. I’ve been having a similar sensation lately. My list looks a little similar to yours. It can be a little frustrating at times because some languages that I find very interesting lack the tooling to build an app (e.g. SML).

    I found the ‘Programming Languages’ course by Dan Grossman on Coursera very enlightening. It was the start of my infatuation with SML and for an appreciation of elegant type systems.

    Thank you for blogging about this. It assures me I’m not crazy for feeling a similar ‘pressure’ at this stage of my life.

    1. I think if your goal is to find a language to work in, it’s very reasonable to exclude the ones that don’t have practical tooling for apps. I see this in e.g. Idris right now. On the other hand, if you’re interested in advancing language research or in learning modes of thought to bring to other languages, it can make sense to study an academic language.

      I’m curious: what do you find compelling about SML over Haskell?

      1. The Programming Languages course by Dan Grossman didn’t cover Haskell (SML, Racket & Ruby), but I associate deeply with what Roberto has said here, because taking this course also ignited my interest in PLs beyond that of my daily working language (he is good at what he does).

        Although I would pick Haskell over SML now, I think F Chen described much appeal of SML below.

      2. I don’t find SML more compelling than Haskell, nor vice versa. Don’t have much experience with both to have that kind of opinion. To use a word from a ruby rogues podcast, I’d say that at this point I’m in limerance with SML(and clojure). Haskell is something I want to learn in the future. My impression is that I can learn the basics in SML and jump to Haskell for some of the more advanced concepts.

        1. I always advocate first exploring Standard ML, because of its elegance and clarity and power, before looking at Haskell.

          One of the “drawbacks” of working with Standard ML is that many aspects of Haskell look primitive or limited by comparison. Although both were invented in 1990, the Haskell committee decided not to include an ML-style parameterized module system. The single greatest innovation of ML is its module system, and I sorely miss it when using Haskell. Also, Haskell’s legacy record types are quite limited. Standard ML’s record types are kind of funny too, unfortunately. Keep in mind is that these are 25-year-old legacy languages, after all. Thankfully, Haskell is not standing still. There is intense work going on in addressing many of its legacy flaws because they hamper productivity: overloaded record fields are finally coming soon to GHC, and so is an option to compile a module with strict evaluation by default, and in the works is a module system based on work from the ML community. It is to the Haskell community’s credit that so much work is going into improving and evolving the language.

          1. Interesting! A long time ago I had gotten the (obviously mistaken) impression that Haskell was an outgrowth or follow-on to ML work. In particular I thought that the lazy evaluation was considered a more advanced/experimental idea. Thanks for clarifying!

          2. Non-strict evaluation, lazy types, and type classes are very controversial features of Haskell that the ML community has rejected early on as language features, preferring to support them optionally as “patterns” instead (through libraries, syntactic sugar, or through more fundamental language features).

            Note that the most recent typed languages are a mix of ML and Haskell philosophies. For example, Elm, PureScript, Idris are all pure, but strictly evaluated (providing lazy values through libraries). Elm will eventually have type classes, while PureScript and Idris already do.

            Also, on the ML front, Rust has “traits” which are much like type classes. OCaml is about to get implicit modules in order to provide much-needed type class functionality.

            I perceive that language evolution everywhere has accelerated as far as everyone learning from one another and trying to steal good ideas, as a result of use of spaces such as GitHub for discussion and experimentation.

          3. So given you clearly have a much stronger familiarity with this family, what languages do YOU think are most important right now from a “stretching your brain in useful ways” standpoint?

          4. Cool! I look forward to it 🙂

            Actually if you have the time, the world could really use a layman’s survey of the “hard core” functional landscape, like you’ve been giving me here. It can be baffling trying to understand how it all fits together.

    2. Tooling is critical for a language to really be usable. And people on hand to help, teach, document, collaborate with are critical too. A recent blog post by someone who wanted to do something completely new and awesome but found no takers illustrates this: http://alarmingdevelopment.org/?p=926

      My main languages in the 1990s for real use were C, C++, then Standard ML, OCaml (and some Haskell). CPAN came along and Perl became my main language by 1999; I gave up on Standard ML, OCaml, and Haskell that year because the communities there did not adapt to the Web and to the new leveraging of mass collaboration. I never used Scheme for real (although I learned it in 1992 before I tackled C) because of no unified community. I bit the bullet and joined Java in 2002 because a lot of good libraries were being contributed (and Maven made it easy to stick with Java until I abandoned it for Scala in 2013; Scala was virtually unusable for me until the end of 2012 when many things were stabilized in time for Martin Odersky’s Coursera course). I looked back at Haskell periodically for a decade but the tooling was unacceptable for my real use until basically the beginning of 2014, that’s how bad the situation was. For me, languages are practical tools to get stuff done, not really objects of pure study. I have no shame in admitting that I used Java for a decade. It really was the best tool I thought I had access to during that period, even though I have always loathed the language more than I have loathed any other.

  3. For the record, although I currently use Haskell as my main language of preference for getting stuff done, I wish it were not as popular as it is, because it has many unusual features by design and many omissions. The typed functional languages I preferred to use for real work in the 1990s were Standard ML and OCaml, because of strict evaluation, intuitive cost semantics, C-level compiled efficiency, a great module system, and simple access to mutability and exceptions. But these languages never escaped academia (except OCaml relatively recently), have tiny communities, and from a “get stuff done” point of view, Haskell is still simply more practical (although the life is still full of headaches (an accurate depiction of which is mentioned at https://www.fpcomplete.com/blog/2015/05/haskell-at-front-row ) that don’t exist when using a yet more popular language. It’s great to see Rust up and coming because it is directly based on the ML world’s philosophy and theory with its emphasis on zero-cost abstractions.

    1. Hi Franklin,
      Interesting parcours of language choices. I mostly agree with your reasoning. Given that you really like(d) ML/OCAML, for current work, next to Scala you might also look into F#. I find it a really clean, interesting & practical language with some features I have not seen in any other language (e.g. type providers) & interesting libraries (e.g. mbrace for cloud computation).

  4. Really awesome stuff. A quick question. How are you learning all these languages? I mean are you reading books or reading online reference?

      1. I really like the list and the post resonates with me.
        When I try to learn a new language I often struggle with what kind of projects to do in this new language apart from book examples and exercises.

        Ho do choose or find interesting projects to learn a language?

        1. When I was young (and cheap), especially in the era Before the Web, I would routinely read a book or two about a new (preferably not simply new-to-me) language, semi-BS my way through interviews, and bet that I’d learn well enough, fast enough, to meet the project schedule. I’d built up a pretty respectable track record of being able to do that for a number of years. Nowadays, you’d be a fool to try and build a career on being able to do that; the variety and complexity of languages and other tools has been growing, on at least a respectable power function. Employers and clients now are far less willing to tolerate learning on the job as well…I remember seeing a posting about three years ago that literally said “if you don’t have at least seven of our Top Five tools, don’t bother”. (The same company, a well-known outsourcing firm, was also running different ads asking for 8-10 years of Rails experience — which for 2012 would have been quite the feat.)

  5. I like this post. As for your second list:
    Lua – table/hash usage is very interesting. I think you may apply some table-patterns in Ruby.
    Prolog – you should at least check a new “kinds” of Prolog, for example Picat (functional, logic, memoization etc). You may not use it, but it is worth to know about it.
    Factor – it is a very big and diverse language. I think you may find something interesting in it. If Factor is too much for you then you should at least check smaller concatetative languages like Mouse, Cat or Kitten (I haven’t checked that one). You may find Cat in the web archive org.
    If you work with tables/arrays a lot you should check J or Gura language.

  6. My desire is to go deep with a few well-supported languages, avoid esoteric/bleeding edge when possible.

    Current Languages:
    – Ruby – first and best loved language, though I hate the GIL
    – JavaScript / CoffeeScript – a necessary evil, though ReactJS is pretty great
    – Bash – ubiquitous automation tool
    – VimL – pimp that editor

    New Languages:
    – Rust – when I need a speed boost, or a binary executable
    – Python – for utilities to leverage the ubiquitous pre-installed interpreter
    – Elixir – for multi-core performance & real-time webapps
    – Lua / MoonScript – to write plugins for Redis and NeoVim

    I am impressed with the tooling for new languages Rust and Elixir – much progress in a short time.

    Won’t Do:
    – Node – just hate it
    – Go – because there is Rust
    – Haskell / Closure / Scale / Everything Else – don’t have the time

    1. Here I am speaking of languages alongside their ecosystems. I already know JavaScript; but learning JavaScript-in-context-of-NodeJS would be a structurally similar endeavor to learning any other language-plus-ecosystem.

  7. Have you considered Racket? I’m learning this now and it has been quite an enjoyable experience. I particularly like how easy it is to extend the language or to even create your own language from scratch. It can also be used to work on the problems from SICP!

Leave a Reply to googya Cancel reply

Your email address will not be published. Required fields are marked *