Saturday, December 15, 2007

Why your fancy new programming language choice is probably going nowhere

This week I was CCed on bunch of email threads discussing new/old programming languages. The general idea thrown around in these threads is switching to a completely different language because it has an inkling of a high level concept that might help you. One example would be a concurrency-oriented functional language like Erlang in a new space, like, for example, desktop Windows applications that could use multithreaded computation.

Ok, here's the problem: once a language is established in a space, it's really difficult to dislodge it. So if one application developer switches to Erlang for Windows programming just because it can deal with concurrency better, that won't start a trend worldwide. That person will write a ton of extra code just to get it to work -- hooking Erlang to the Windows SDK (C++/VB) -- and then who supports it? They do! The problem is that it's not up to you, the application developer as to whether or not the primary language gets dislodged. That's up to the platform provider.

The only new language lately that's making inroads on C++ for Windows application development is C#. Why? Because it's Microsoft, of course. They're the only ones who can push on that sort of thing and make a difference because they'll be the ones to support it, not leaving it to the application developer to either buy third party support or support it themselves.

Java is a really great example of failing to move in on established spaces. In 1996 or 1997, Java was hugely hyped and being adopted by many. Yet the original "write once, run anywhere" promise made back in 1996 or 1997 has been destroyed by the same old C and C derivatives (C++, Objective-C) on all platforms (Windows, Mac, Linux, Unixes). Because really... why would you bother with Java when your platform API is in a C-language? You'd get the chance to try to shoehorn Java into working in environments constructed entirely around C.

However, Java did make some good inroads into unexplored spaces, namely the web and mobile devices. If a website isn't running PHP in this world, it's probably running Java. And most mobile devices (except iPhone, Qualcomm's BREW and Windows Mobile devices) have Java runtimes.

Speaking of the web. The web is probably the only current area that won't resolve the language issue anytime soon -- at least on the back end. A web application back end interface to the client is comprised of text layout instructions sent to a user client (HTML). You can interface with this easily in any language you want. Open a socket, send HTML through it, done. This is why it's really pretty simple to have a language like Ruby come out of nowhere and get a lot of steam in the web space.

One thing is settled, I think, and that is Javascript is the language we'll be using on the client side. Yes, Flash and actionscript will still be used for widgets and stuff. But Javascript is what you use for applications on the web, like Gmail, because all clients interface with it. Plus, actionscript and Javascript are supposed to merge with ECMAScript 4.

By the way.... the threads included a bonus of the age-old LISP angst that is well known to Slashdot readers. Get over it already. This isn't because of some worldwide anti-LISP conspiracy. The world won't write new code in LISP for the same reason they wouldn't use COBOL. There's no momentum there anymore. So drop the LISP persecution complex.

No comments: