Wednesday, June 27, 2007

The next big language

I believe the large success that Ruby has enjoyed has made programmers eager to find the next big language (NBL). The NBL holds a lot of promise for the aspiring software developer. Become an expert in the NBL and you'll be able to command a premium while riding the next wave. If your lucky you may also design the testing or build framework that will ensure stardom in the NBL community.

So, how can you be ahead of the curve? How can you be one of the first to master the NBL? Tim O'Reilly already told us how to start: watch the Alpha Geeks.

The NBL might be a language that already exists. Dave Thomas recently blogged a bit about Erlang. Avi Bryant continues to invest his time in Smalltalk. And, it would be foolish to ignore Paul Graham and the Lisp community.

Then again, the next big language might be Ruby with YARV, Rubinius, JRuby, XRuby, or IronRuby. It could also be a language that exists but has a small community such as IO or Boo. Or, it could be a new language with more or less rope.

I think part of the problem with guessing what the next big language will be is that the question assumes there will be one language that can satisfy all your needs. The truth is, differing systems have very different needs. How many web applications have you worked on that actually needed an object oriented language? Because of the request/response nature of the Internet, most web applications could easily be built using a procedural language. There's tons of PHP sites that work just fine without objects. Sure, some sites are complicated and need a bit more than PHP4. For example, building Yahoo Store must require an Object Oriented language, right? While Yahoo Store was probably a bit complicated for PHP4, Paul Graham lists Lisp as their secret weapon of success. I'm not implying that OO languages are better than Lisp or vice versa. I'm simply pointing out that a language choice is probably not something worth making at an Enterprise level. The same is true when looking for the NBL, you aren't likely to find one that is perfect for solving all possible problems.

So then the question becomes, of the various NBLs of the future, which one is designed to address the problems you are interested in? If multi-processors and concurrency interest you, Erlang might be the ticket. If you love building web applications, Ruby/Rails isn't likely to go away any time soon. Or, if you want to build on years of experience with the same language, Smalltalk and Lisp have plenty of lessons for you to learn.

In my opinion it doesn't matter what NBL is. Most languages have unique solutions that allow you see problems in an entirely new way. That's why the Pragmatic Programmers suggest that you learn a new language every year. So instead of looking for the NBL, learn a language with a paradigm that differs from the one you use at your day job. For example, if you are currently using an OO language, learn a functional language. The established languages of today have plenty of lessons for you to learn. Knowledge of Ruby, Smalltalk, C#, Java, Lisp, Erlang, PHP, Perl, etc will ensure that you will quickly become proficient in any language you adopt in the future.

If you still insist on trying to predict the future, here's something to consider. As an industry we spent many years learning the lessons of procedural languages. Next, the majority learned the lessons of statically typed object oriented languages. Now, more than ever, we are learning the lessons of dynamically typed object oriented languages. If I had to guess, I think sooner or later the masses are going to figure out that functional languages also have power to offer.


  1. Hi Jay,

    In this great quest for the NBL, I want to mention here the Scala language.

    This is the language I chose to learn this year, for reasons I will certainly write soon in a blog entry. The short story is:

    -integration with java (I can use it at work)
    -nice merge of object-oriented and functional concepts
    -not too much finger-typing thanks to type inference
    -an actors library, allowing some nice erlang-like usages
    -parsers and combinators
    -all sorts of tricks and features that allow concise and structured programming (pattern matching, options, traits, implicit defs,...)

    On the other hand, the language itself is not everything, and Scala is still missing some "basic" librairies that I really like from ruby for example: rspec, rcov, rake and all sorts of gems.

    Anyway, this is really a language worth discovering.

  2. Anonymous9:11 AM

    Hi Jay,

    I do not know if you are familiar with Steve Yegge's blog, but he has been talking about the Next Big Language for quite some time.

  3. Anonymous2:55 PM


    Thanks for the link, I hadn't seen it yet.

    This entry was based on conversations I've had recently.

    Even if Steve does know what the next big language will be, I think it's important to know the other languages I mentioned. You've got over a year until Steve thinks the NBL will be out. That's time to learn a few languages.

    Cheers, Jay

  4. Anonymous3:48 AM

    Its possible to list the properties of the NBL based on the success of languages to date

    1. It will have array, hashes as basic data types
    2. It will be object-oriented
    3. It will be dynamic (no static typing allowed)
    4. It will have code blocks/anonymous fncs that can be passed around a la ruby/smalltalk or something equivalent

    Here are other features I believe an NBl should have

    5. it will be as simple as possible both conceptually and syntactically
    6. It will be able to deal with concurrency well
    7. It will be prototyped-based (no classes)

    My candidate is IO.

  5. Anonymous7:04 PM

    Just to be clear-- Ruby is not a big language, now, so there is a chance that if they add static typing, some major speed improvements, and support for concurrency-- maybe it will be.

    features of the nbl:
    *single assignment for variables
    *first tier support for arrays, *lists, tuples, maps
    *able to specify shared memory or message passing
    *dynamic typing allowed
    *static typing must be supported

    I think there is a good chance the language will be implemented on the JVM. But will the JVM provide the multi-processor concurrency support and support hot-swapping code? Maybe. Maybe not.

  6. Often sneered at since it is built on Java is Groovy (and all the cool kids have long since eschewed Java for something else) ..

    With Groovy/Grails you get the proven heavy lifting and staunch maturity of Java, all the APIs and (much that I loathe to admit it) all the big app servers, if that is you poison.

    And within that context you get

    - All the OO Java has
    - No mandatory static typing - its truly dynamic (but you can still type things if that's your preference)
    - Closures
    - Great language semantics simplicity over java (elvis operator, no semi-colons, currying)

    And compared to the NBL and all the hype of the future, its here now, and working wonderfully for those who are committed to it..

    It seems however that nobody has the time to go out on a marketing and hype extravaganza like the Ruby folks.. Guess we're all busy delivering production codez... ?

  7. Oh I meant to also say..

    Groovy has a great and wonderfully expressive implementation of BDD, quite similar to RSpec - EasyB (

  8. Jay, a great article with a sensible recommendation. I can't help thinking, though, that the NBL might not be a rational choice made by enterprises. For example did enterprises really choose Java or RoR ? No they crept up through developers, enterprises merely adopted them.

    I've been playing around a lot with Scheme recently - initially to learn a functional language but having used SISCWeb, I'm finding that it is massively more productive than RoR for Web Apps and offers compatibility with Java. The main reason is that continuations make the web work properly.

    I predict that whatever does become the NBL it will have to support continuations.


Note: Only a member of this blog may post a comment.