In recent talks, I’ve been using a graphic from State of the Computer Book Market, written for O’Reilly Radar by Mike Hendrickson, and it’s been preying on my mind. The more I think about it, and about the programming-languages landscape, the more I think that this picture isn’t changing much any time soon. The landscape is stable.
Here’s the graphic, and if you like it, you really ought to go read the whole article, which has lots of meat and other graphics too. Also, I think the IT industry owes O’Reilly a major vote of thanks for buying the data and investing in the analysis.
Let’s just sort these out by date of introduction: C/C++ (1972), SQL (1978), C++ (1983), Visual Basic (1991), PHP (1994), Ruby (1995), Java (1995), JavaScript(1995), C# (2001). Kind of, well, elderly, aren’t they?
What’s Hot? · Are any of the bars on the graph about to shoot up and dwarf the others? I doubt it; the only two groups with significant growth recently are Ruby (as a function of Rails) and JavaScript (as a function of Ajax).
I think Ruby has some more upside; as the wave of Rails adoption gets it in front of more programmers, a certain proportion will be seduced. It seems that Java programmers are particularly vulnerable to Ruby’s charms.
JavaScript too; I’d say why I think so, but Steve Yegge already did (albeit without mentioning its name) in The Next Big Language.
I’m not sure, though, that I can see JavaScript really breaking out of the browser ghetto. It doesn’t provide anything, as far as I can see, that you don’t get from one of the other candidates. On the other hand, we’re going to be needing a lot of browser programming for the foreseeable future, and JavaScript is how you do that.
So yes, some of the bars will inch up; but then they’ll be fighting the Law of Big Numbers. It’s plausible to get from nowhere to half as big as C++ and do it quickly; but then you’re into the territory of sunk investments and big-community dynamics and so on. Rapid qualitative growth, beyond a certain point, is just hard to believe in.
What’s Doomed? · Are there any here that might go away? The only one that feels threatened at all is VB, wounded perhaps fatally in the ungraceful transition to .NET. I suppose it’s unlikely that many people would pick VB for significant new applications. Perhaps it’s the closest to being this millennium’s COBOL; still being used a whole lot, but not creatively.
Some might glance in the direction of C and C++, but they’re totally with us for the long haul, C at least. C, among languages of its kind (vehicles for clean infrastructure code that’s right up against the metal) is a good one. C++, among its peers (object-oriented languages for writing applications), is very far from the best.
Having said that, C and C++ were the default choices, for enough years, for writing important pieces of the platform, that their future is secure.
I suspect that PHP’s market share gets chewed away at by Rails as people notice the sharp contrast in maintainability, but there are a lot of good PHP-based applications, which should keep it on the main stage for a while.
What’s Missing? · Are there any other languages that we can reasonably expect to emerge from the background and be on this graph a couple of years from now? I notice a distinct lack of functional languages (Erlang, Haskell, Scala), and what with “scaling out” and many-core and so on, I’d be unsurprised to see a break-through from that direction. But Functional Programming is a challenge, and I’d also be unsurprised to see enough FP bolted onto the side of the conventional O-O wisdom to get us through, in combination with throwing enough memory on servers to keep those cores busy running processes not threads.
I also notice that Ruby’s the only really sophisticated dynamically-typed language on the list, and there are a lot of really smart programmers who’ve been doing wonderful work in Python for years and see no reason to stop. Among other things, Python (for the moment at least) runs a whole lot faster than Ruby, plenty fast enough to be used for compute-intensive work; and at some point that has to matter. So, maybe Python.
Client Apps, Web Apps, RIAs? · This past year, there’ve been waves of enthusiasm over “Rich Internet Application” frameworks: the DLR, Apollo, JavaFX and so on. Among those, I have a soft spot for JavaFX not only because we cooked it up but because it’s unambiguously open-source and doesn’t constitute a bet on a vendor.
Still, I think the jury’s way, way, out on the RIA notion. Does the expanding scope of Ajax leave a big enough gap to grow a new ecosystem in? And, at the end of the day, will there be enough richness to seduce enough people away from the considerable charms of the browser and its reassuring “Back” button? We’ll see.
Mobile · People—really smart people—keep pointing out that there are ever so many more phones than PCs, and they’re biting into the digital divide, and that when you’re writing an app, you shouldn’t expect it to run just on something so old-fashioned as a “computer”.
People keep saying this and it keeps not happening, for me at least. I’m starting to think that when the time comes that the mobile phone has become a mainstream application platform, it’ll have evolved to the point that you use about the same range of programming techniques and tools and languages. So I’m not sure it’ll be a major disruptor of the O’Reilly graph.
In fact, my bet right now is that nothing will.
Comment feed for ongoing:
From: Tkil (Jun 04 2007, at 22:37)
Where's Perl in all this? I know it used to be a huge deal, and especially with O'Reilly doing the analysis, I'm surprised that it's not on this list. It might be missing from the source data, but I have a hard time believing that Ruby is on the list while Perl isn't.
[link]
From: Robert Sayre (Jun 04 2007, at 23:18)
"I also notice that Ruby’s the only really sophisticated dynamically-typed language on the list"
This seems unsubstantiated. How is Ruby "more sophisticated" than JS? It certainly had more time ruminate on syntax, and it shows. Does it have a security model that can allow iframes on MySpace pages? Does it proceed at all costs? Does it have multiple popular, mostly interoperable, mostly documented implementations? Remember, we're talking Mozilla, IE, Opera, Safari, Flash, Acrobat, etc.
It seems to me that the "browser ghetto" is where everyone wants to live. So maybe the other neighborhoods are overpriced places built for boring people.
[link]
From: Geoff Arnold (Jun 04 2007, at 23:25)
Your first commenter asked about Perl. Too slow, and unmaintainable. One day we'll look back on it and shake our heads in disbelief: what were we thinking....
I've decided that I'm going to learn one new language this year. Erlang.
That said, an implementation of Erlang (or close facsimile) running on the JVM would be awesome.
[link]
From: Tim (Jun 04 2007, at 23:39)
Geoff, are you serious? Perl is faster than more or less all of the above. Its problems are otherwise.
[link]
From: Giovanni Corriga (Jun 05 2007, at 00:03)
Speaking of dynamically-typed languages, I'd love to see a book on Smalltalk and Seaside. I hope I won't have to write it myself ;-)
[link]
From: Janne (Jun 05 2007, at 00:19)
Mobile phones: I don't see it happening for the foreseeable future. Not because of the technology (a modern handset could run anything you need in a pinch). Because of the business model.
I'm looking for a new phone, and the price charts for online stuff are frankly frightening. Open the online menu? That's 21 yen worth of data. Airline info? Around 65 yen. GPS is free, but get a street map snapshot around where you are will cost you 55 yen - and navigating to a point using the map has a cost of 55 yen per 500 meters. Reading a PDF (timetable or whatever) is about 185 yen per 100kb, but of course you often don't know just how big a given PDF is. A typical application (game or something) will normally cost around 300 yen - a month, plus the data cost of downloading and verifying it each month.
As far as online services go, I'm scared to death even to open that menu choice. On my current phone, the first thing I did was to put a PIN-code lock on all online stuff except email so I wouldn't access any of it by mistake. It isn't that the price is necessarily high, but that I feel like I'm slowly being bled dry, and have to constantly worry about what my next menu selection will cost and whether it's worth it to me.
Do you want to have a word processor where you pay per word? Where each spreadsheet recalculation will cut another small chunk of money out of your purse? I don't. But until the micropayment approach to networking disappears that's what we'd be offered.
[link]
From: Preston L. Bannister (Jun 05 2007, at 00:23)
Note that if you are going to get good at web applications, you pretty much have to use Javascript. Once you have learned Javascript *well* for the client, why not save some wear on your brain cells and use the same language on the server?
Given that Javascript embeds very nicely in Java, you have ready access to the entire universe of existing Java code.
One fewer languages to remember has got to improve productivity. We already have HTML, CSS, and Javascript on the client. We will have C/C++ and Java on the server (for at least some applications) pretty much forever. As a 'script' language are either Ruby or Python really that much better than Javascript?
[link]
From: Kevin Marks (Jun 05 2007, at 00:46)
I think you're right on both counts - Javascript support is growing on phones; HTML+CSS+Javascript is the only developer platform that even Steve Jobs has to support on the iPhone.
[link]
From: Stefan Tilkov (Jun 05 2007, at 01:59)
My guess (nothing more) is that you're wrong regarding VB, as VB.NET is probably hidden in the .NET languages block and the separate "Visual Basic" really means VB 6.
[link]
From: Sérgio Nunes (Jun 05 2007, at 02:01)
Perl is strangely missing from the figure.
On the other hand, I think that the RoR framework is still too young to make definitive statements about its maintainability.
[link]
From: KISS (Jun 05 2007, at 02:42)
Don't forget that clean intuitive languages have less need of being explained in a book you just "grok" them
- Now "Grok" that would rock as a name of the next big language ...
[link]
From: anonymous (Jun 05 2007, at 04:36)
I agree with Peter why not use Javscript on the server? Look at all this good stuff coming up in version 1.8. Check out the cook Workerpools in Google Gears!
http://ejohn.org/blog/javascript-18-progress
[link]
From: Juri Pakaste (Jun 05 2007, at 04:51)
Dunno about the Python books - seems unlikely unless Django or something takes off seriously. There have been Python books over the years, the first edition of Mark Lutz's Programming Python, published by O'Reilly, came around ten years ago. But the documentation shipped with Python is better than pretty much anything available for free for Ruby. The tutorial and language reference are good and mean that there's pretty limited need for extra books.
[link]
From: Laurent Szyster (Jun 05 2007, at 05:07)
"So, maybe Python."
Now, why did Sun not pick Jython ten years ago instead of a less capable JRuby ten years later?
Let me guess ...
Oh yeah!
Replace "VB" with "Java" in your piece about COBOL and then it becomes crystal clear why Sun could not possibly not promote ECMAScript or Python to inject a healthy dose of dynamism and functionality into the JVM: because it could legitimize a migration path to a truly free and open, more creative, more productive and more efficient plateform.
So, instead of improving the stable Rhino or Jython and shoot itself in the foot, Sun's has wisely decided to invest in a less than optimal choice to script the JVM (to say the least).
Not much new here, indeed.
That's perfectly in line with other past technical choices like EJB 2.1 or WS-*: when it comes to exploit the lack of technical information and expertise of your customers, worse is definitively so much better off. I mean, slow, complicated and bug-prone Java applications do generate more pricey consultancy, premium hardware sales and expensive maintenance.
Don't take me wrong: I'm making a living of it too.
[link]
From: James Justin Harrell (Jun 05 2007, at 06:34)
I think it would be fairly easy for a new language to gain a lot of popularity if it just had one killer feature: an extremely easy transition. Currently, porting from one language to another is such a huge pain that languages can really only take over as old projects die and new ones are started.
Even if such a translator requires complicated and difficult AI, I feel confident such a program will eventually come along and boost a new wave of programming languages into popular use.
[link]
From: Tony Fisk (Jun 05 2007, at 23:34)
Is there really any incentive for a new language?
Has some software paradigm been recently identified that isn't adequately covered by the features of existing languages?
The only ones I can think of are aspect oriented programming (which, on brief acquaintance, seems like a complex solution in search of a problem), and multi-core architectures (which I naively suggest is a semaphore issue).
[link]
From: William Newman (Jun 06 2007, at 06:36)
I seldom use C++ these days (using mostly Common Lisp, plus some C and Perl), but I remain impressed with it. I think if you define C++'s niche and peers more narrowly, it deserves some respect --- though of course narrowing its niche does reduce the number of books it deserves to sell.
Your description of its peers is historically correct: people treated C++'s niche as including even soft flexible applications like web browsers and word processors. That was arguably a questionable idea even back around 1990 (I note emacs' design choice has worn well) and I think it is pretty clearly a bad idea today. But there remain various areas which seem to benefit from C-style close-to-the-metal-ness, even down to static typing and lack of GC, but where other missing abstractions in C are just a pure headache. I'd very likely choose C++ to write a new 3D game engine, at least the hard layer. C++ wouldn't be my first choice to write an optimizing compiler --- but it would probably be my first choice among the languages in the illustration. And C++ also seems like a reasonable choice for many simulation and optimization engines. Also note also that even though today everyone's desktop computer can handle extremely complex software, smaller computers are extremely common (because they are extremely cheap). For years GCC has cheerfully compiled C++ down to AVR microcontrollers, e.g., while for fairly good reasons the other languages on the list tend to lag behind.
[link]
From: Greg (Jun 06 2007, at 06:47)
Kevin Marks mentioned JS+CSS+HTML on the iPhone already, but he seemed to be thinking of the future. I don't believe the "we're worried about third-party apps on the iPhone" hype. There are already hundreds (thousands?) of Dashboard widgets developed by third parties and available for convenient download. They are built with JS+CSS+HTML and executed on the WebKit engine behind Safari. You know, the same WebKit engine that runs on the iPhone.
Other than the performance-critical parts of the iPhone software (music/video playing, web browsing, phone calls, maybe email), I'm betting that the majority of the software (and particularly the UI) is already built as Dashboard widgets. There might be some JS API extensions to do interesting things with the multi-touch interface, but I expect that most of the existing available Dashboard widgets will wind up appearing on the iPhone almost unaltered over the course of the next year, or even the next few months.
[link]
From: Ted (Jun 06 2007, at 08:37)
What are the units on that y-axis?
[link]
From: Pierre Phaneuf (Jun 06 2007, at 16:26)
I agree with Robert on Ruby not really being any more sophisticated than others. It is not lacking, though, whereas I see Python having only lightweight support for closures/lambda, and Guido's dislike for the functional constructs like map, filter and reduce.
Ruby obviously takes much from Perl, from Matz's own admission, and even a certain flavour, just all cleaned up. The only disappointing part is going from one of the fastest interpreter to one of the slowest (but of course, careful design can help mitigate this).
There's a command-line JavaScript interpreter hidden in the Mozilla build tree somewhere, if I remember correctly. Someone ought to package it up, one of these days.
C is in a bit of a weird situation, I think, where it's just about obsoleted by C++. In the worst case, you write your code as if it were C, and you get better type checking, and various other little extras. One of my common method for finding subtle bugs in C code is to add "-x c++" to my gcc's CFLAGS. There are very few situations where you have to use C over C++, usually at the very lowest end of the spectrum, usually having to do with being able to put things in the text segment rather than the data segment.
[link]
From: Joe Cheng (Jun 08 2007, at 00:25)
Sad to see Lisp so far down the list--while I'd be hard pressed to justify actually choosing Lisp for a project, learning it has made me a far better Ruby and C# programmer.
[link]
From: Jay Carlson (Jun 08 2007, at 01:37)
I wish I could get more excited about Ruby, but it's really just Smalltalk with fast startup on Unix, a "cooler" Perly syntax, and a license to fix 25-year-old misdesigns that the Smalltalk-80 world can't. ("Mutable strings? In _my_ programming language?")
The language you're missing is Lua. Borrowing essentialisms, here are some analogies:
Lua is essentially PostScript with Algol syntax.
Lua is essentially Scheme with dicts instead of lists.
Lua is essentially Tcl for C integration except it acknowledges datatypes other than strings might exist.
Lua is essentially JavaScript if language weenies could have gonged out DEEPLY BROKEN CONSTRUCTS AT THE CORE OF THE LANGahhhhhh, subcutaneous diazepam
Where was I? Oh right. It's hardly going to matter. Lua's also the WoW console language and the HL2 mod language of choice. So it's really just a matter of time before the kiddies manage to sneak it into the enterprise.
[link]
From: Ezra Cooper (Jun 12 2007, at 04:15)
Please keep in mind that this data is gathered from *book sales*, and by who-knows-what methods. Okay, it's collected by Nielsen, so it's independent of the publisher (we hope)--but we still don't know exactly what constitutes a "sale" (are used sales counted, for example?). Also these figures are apparently only for the US market.
More to the point, there may be systematic bias in terms of which languages push more books, which languages happen to have the best books, and so on. I don't accept that these figures are indicative of language popularity per se.
[link]