rss feed

blog - the Next Big Language doesn't matter

posted by witten on February 11, 2007

In a recent post (http://steve-yegge.blogspot.com/2007/02/next-big-language.html), Steve Yegge describes the features the "Next Big Language" must have in order to take over the world, including things like C-like syntax, dynamic typing with optional static types, and a decent IDE.

Any language lucky enough to support all of these must-have features would presumably be accepted much more quickly than less well-endowed languages, and therefore would eventually be wildly popular among developers.

His premise is that any language you invent, unless it has these certain features and is backed by industry heavyweights, is doomed to utter obscurity and therefore failure.

This is a familiar refrain. In an excellent series of blog posts on what features a more popular Haskell-like language might have (http://toomuchcode.blogspot.com/2007/02/part-1-programming-and-metaphorical.html), Ryan Brush claims that:

And that:

However, I simply don't accept the premise. It may have been that ten years ago, your choice of languages was restricted by what binaries or VMs your customer's desktops could run. And in that case, the relative popularity of a language really did matter. If you chose a language whose runtime none of your customers could install or use, or didn't come pre-installed on your customer's computers, then you ran the risk of not being very successful.

But today, many applications are web apps served off of remote servers. Except for client-side UI code, large swaths of application logic live on a climate-controlled, colocated server that the customer never touches except via HTTP. That means that the server can equally well run Lisp, Python, Befunge, you name it, without having any adverse impact on your customers. As long as it serves up the web application the customer wants, it doesn't matter whether your language is the Next Big Language or the Obscure Dialect Du Jour.

Now, before you start getting all in a tizzy, let me state some rather important caveats.

I am fully aware that local, native applications aren't going away anytime soon, or ever. And for those, Yegge's Next Big Language will probably be very handy. And yes, I know that he's probably talking about the next version of JavaScript, which will even play a large role in web applications.

I'm also aware that some web applications are shipped to customers, and so do have runtime and platform restrictions. Witness Fog Creek's much-lambasted Wasabi.

But even so, there will still remain a large contingent of server-side application components that you run on your own servers, and so you'll be able to write those apps in any language you want. In other words, although there will always be many areas of applications in which the language does matter, there will similarly always be many server-side applications in which it simply doesn't.

So, if you can use any language you want on the server, does language popularity matter at all for server-side applications? You better believe it does. As Ryan Brush points out, language popularity has a direct impact on whether your risk-averse employer will let you use it at work. Nobody has ever gotten fired for choosing Java.

But again, I'm not making an argument that you can happily get by using Bob's Podunk Lisp Variant when you work at IBM or Sun, but simply that there are still some specific areas of application development in which you can use pretty much any language you want. Now, this may be relegated to the server in the form of web apps, and you may have to be working at a smaller and/or less stuck-in-the-mud company to convince your boss to let you use your language of choice, but there still are many areas in which the Next Big Language just doesn't matter one whit.

Okay, so then how does popularity affect writing server-side apps for progressive organizations that will let you use something other than Java, C#, or ECMAScript 2007 Enterprise Edition? Well, there's still the question of standard and third-party language libraries, where the network effect has a large impact.

For instance, if your language is so obscure that no one's writing libraries for it, then it will be extremely difficult for any developers, new or experienced, to get anything done. In other words, if you have to write your own HTTP client every time you want to pull something down from a URL, because you're only the eighth person who has ever used the language and the first seven used it to write nothing more variations on the Fibonacci sequence, well then you're going to be giving up on it pretty quickly in favor of Java.

But if the language happens to be moderately obscure while still supporting enough of a self-sustaining community to contribute, maintain, and document the language's standard libraries, then the language can be useful enough to developers for day-to-day use. Who cares if Microsoft is using your language as long as it's got built-in libraries for doing everything you need to do and runs on all the machines you need it to run on.

So unlike Steve Yegge's characterization, that language popularity is an all-or-nothing proposition, there is a fine gradient between total obscurity and complete corporate adoption. And along that gradient there lie varying degrees of usefulness for varying types of software development. If it so happens that your language of choice is just popular enough to be useful for the kind of applications you're developing, then you can continue to code in peace without having to worry about what might be next or big.

Oh, and for all you Linux/BSD nuts out there, as an exercise, run through the above argument substituting "OS" for "language". You'll notice that the Next Big OS doesn't matter either.

4 comments

Write a comment!