Technical Architecture is a Form of Investing. I’m reminded of this sort of thinking because of recent news from RubyConf 2007.
First, IronRuby joins Ruby.NET in providing a Ruby runtime on .NET. They’re at different stages of completeness, and building on different .NET runtimes (DLR vs. the regular CLR), but the important point is that Microsoft is investing in dynamic languages. Is it ready for production today? Probably not. But keep an eye on Ruby, Python, and JavaScript if you’re a .NET developer.
Second, JRuby 1.1b1 has been released and as expected is considerably faster (see item #5 in this link) than the standard “MRI” runtime. JRuby joins Jython and Rhino in providing a JVM-based runtime for a dynamic language, with features designed to help developers mix and match the dynamic language code with Java code.
See the trend here? Python, Ruby, and JavaScript are emerging as the dynamic languages of the future for .NET and Java developers.
The hard work done by Sun and Microsoft to make their VMs work well is being leveraged by the next wave of languages. Threads, high performance I/O, memory management, and portability are all features that are quite expensive to get right, and the .NET and Java platforms have pretty much achieved that at this point. (Piggybacking newer, higher-level languages on these mature runtimes means that you get a mature new language runtime faster than if each language’s runtime were built from scratch and painstakingly debugged in isolation from the others.)
There are still some hurdles (performance, type safety fears, lack of mass market acceptance, ECMAScript 4 standardization and adoption, etc.), but in 2 or 3 years, things are going to change dramatically in the web application development world. The seeds of this change are already sown, and it’s just a matter of time. Threads, SQL, OOP, and garbage collection are all features of web application architectures that were initially controversial, but have now met with general acceptance. Dynamic languages are clearly the next step.
Obviously, Java and C# are far from dead, and in 10 years people will still be coding in Java and C#, because as with other languages like C and assembly, the newest and highest-level language isn’t automatically right for every project. But if you’re building web applications, most of what your code does falls into the categories of string manipulation, collection operations, or file and socket I/O. Image processing, crypto, full text search, and other CPU-heavy, byte-twiddling features may be part of your application, but you’re not writing the image scaler, RC4 cipher, or inverted index yourself; those are done in a library, probably written in C, and you’re just calling it. So your needs are likely to be similar to the sweet spot of dynamic languages: maximum expressivity and the fancy features to let you write clever code, making you productive and making the code as clean and elegant as possible. In other words, they put developer productivity first (lower labor cost and shorter development schedules) at the expense of runtime performance. Since hardware gets cheaper over time but code gets uglier over time, this is probably the right choice to make for most web application projects.
Another interesting benefit of layering instead of starting over is that the integration between dynamic languages and Java or CLR languages is much nicer than managed vs. unmanaged code in .NET or, even worse, JNI in Java. That is, it won’t be a bloody mess to mix and match code, from a technical feasibility standpoint. This matters, because The Big Rewrite is among the Things You Should Never Do. But little bitty rewrites are fine, especially if you have a thorough test suite to help you avoid breaking things. (By the way, dynamic languages are great for writing automated tests.)
Which of these three (JavaScript, Python, or Ruby) is going to be dominant 5 years from now? I don’t think any of them will be. The dynamic language community is fragmented, and the various vendors and big sponsors of these three languages are fairly entrenched already. Microsoft is investing in all three; Google has standardized on Python and JavaScript to the exclusion of Ruby; Sun has hired the JRuby team; Mozilla is heavily invested in JavaScript; Adobe supports JavaScript in AIR but not Ruby or Python, etc.
In fact, if you encapsulated the glue code sufficiently well, you could mix and match JavaScript, Python, and Ruby in your application, and port your hideous hydra between the JVM and .NET. You would be wasting a lot of effort since the three languages are largely similar, but you could do it. Alternatively, you could create a portability layer between the DLR and the JVM a la WxWindows, and write-once-debug-everywhere in a more productive language than Java.
These are all repugnant ideas, but only because as I write this and as you read this, we probably realize that to attempt this today would be a huge task. But what about in 2010? Probably not so gross. What about an application that could be executed on Silverlight, AIR, Firefox, SWT, and Mono, unmodified? How about a mobile app that runs on smartphones regardless of the runtime (.NET vs. J2SE)? Not gross at all, and not unthinkable if your app is written in JavaScript using some kind of portability layer that doesn’t exist yet.
In the longer term, JavaScript (a.k.a. ECMAScript 4) is likely to become extremely popular. As far as I know it’s not quite a perfect fit for Steve Yegge’s The Next Big Language, but it’s the closest thing there is, and it has two critical advantages over Ruby and Python that will make it successful: C-family syntax (which makes development tools cheaper to build) and effectively unanimous buy-in from vendors and developers.
So, what about the other dynamic languages that people are using in large numbers today? What’s going to happen to ActionScript, CFScript, PHP, and VB?
ActionScript and CFScript are pretty close to JavaScript by design; I’ve read that ActionScript 3 is actually compliant with the ECMAScript 4 draft specfication. It’s pretty clear that Adobe is betting on JavaScript. In the near future (2 or 3 years) I predict that Adobe will rev its products and support ECMAScript 4 across the board.
PHP and VB.NET/VBScript will hang around for a long time because they’re approachable and already very popular, but they’ve already peaked, and will steadily decline as developers switch to C# (on the .NET side) and Rails (on the Linux side), and then JavaScript as soon as a serious web app framework and an ISP-friendly runtime exist. Microsoft will keep investing in VB to keep customers happy; Yahoo will keep investing in PHP because it is so heavily invested in PHP already; new developers will find PHP to be an easy starting point for light duty web development, with tons of documentation and free applications that they can download and hack. But PHP will not inherit the kingdom from C# or Java, and the languages which do achieve mainstream success after C# and Java will do everything that PHP does language-wise, and the market momentum around those languages will make them better than PHP at what PHP does. Developers will ask themselves why they would write the client side and server side in two different languages, especially when the server-side language is more expressive and has better portability and libraries. That’s not true yet, but it will be in a couple of years. In 5 years or so PHP and VBScript will go the way of Perl CGIs: still used, but by a community a tenth of the size it is today.
What about the new Java-based dynamic language, Groovy? Groovy is interesting, but it’s too late. The Java mainstream of vendors and developers only recently managed to convince the world of “serious” C++ developers that automatic garbage collection and JIT compiled bytecodes can actually work in a high traffic context. The next battle, to promote the dynamic language features that Java lacks but which Groovy brings, will take years to fight. Once a developer makes a decision to not use standard Java, Groovy is on a more or less level playing field with the JVM-hosted versions of Python, JavaScript, and Ruby, but each of those languages has far greater adoption than Groovy, and each of them has greater opportunity for leverage on other runtimes than Groovy. For a Java developer, once the door is opened to other languages, the only advantage Groovy has is that its syntax is familiar. Compare this to JavaScript which web developers also need to know how to use; why learn a third language (Groovy) in addition to Java and JavaScript? Over time the simplicity of coding and debugging in JavaScript on client and server, together with dynamic-language productivity, will overcome the momentum of the Java standard, and web developers using server-side Java now will gradually replace it with JavaScript on the JVM. Conservative attitudes in the mainstream Java community (including Fortune 500 companies and the many offshore development firms that write code for them) will make this take quite a while – probably 5 years before JavaScript becomes a common part of the architectures that currently use J2EE, and 10 years before Java goes the way of COBOL (maintained forever but not used for new projects).
So in conclusion, keeping an eye on the future value of a technology, including who’s investing in it and who’s talking about investing in it, is critical to making your own investments today. In five years you’re not going to be using the same technology stack that you are today, and your project’s success and your own salary will be tied in large part to how well you invested today.
*Extremely* interesting article. Very thoughtful, and covers a lot of angles. I would differ in a few points, however.
In five years you might be using the same software stack because you invested in it today (and over the intervening five years) and it’s hard to change. This is probably more true of some investments than others. For instance, I spent the last 10 or so years doing web development on Lotus Noets & Domino. (It makes easy stuff easy, but hard stuff a pain in the rear.) It is (in my opinion) hard to switch away from for several reasons:
1) it’s so different from everything else, so it’s hard to make a jump to a different platform
2) it offers features that nothing else really quite matches, so despite its pain points there are things that are hard to give up
3) it tends to be used by BIG companies, which are slow to change no matter what.
I’ve made the switch to working primarily with Ruby (requiring a coordinated change in clientele!) and find that certain mental transitions are difficult. It’s like an English speaker learning Latin and having to figure out declensions. English is verbose, and sloppy, and inconsistent, and lets you express anything a bazillion different ways, while Latin seems to be fairly consistent and principled. (Perhaps I think that because I don’t know it well enough, but that’s another matter.) So take the obstacles for one person to make the change and multiple them across a whole company.
I’ve been eyeing other technologies for a long time. I kind of skipped the Perl wave back in the mid 90s, even though I found it very interesting–there just weren’t any opportunities for me to use it and get paid for it, so gaining any proficiency was not realistic. I flirted much longer and harder with Java, but you can’t really learn something well until you use it in real-world projects. (At least that’s my experience.) I looked at Rails for a long time before deciding this was the right move to make. And I’m not likely to give up that investment of thought and effort so quickly.
So I might be using Rails for the next 10 years…
Also, regarding JavaScript: you’re right in everything you point out, but I think it’s important to also notice that people using JavaScript for the browser is often (most often?) using a layer on top of it that makes it much easier and much more Ruby-like. Take Prototype and Scriptaculous, or jQuery. Programming with those hide so much from you that much of it ends up looking (to my mind) more like Ruby than like JavaScript. I don’t know, but I wouldn’t be surprised if that gets carried over to things like AIR and ActionScript. (Just a wild guess… since I know next to nothing about those two things.)
It also seems like that more and more things will support multiple languages, so maybe in five years we’ll be able to use Ruby in our Flash applications
Nice post!
Personally to me all languages are essentially the same: to convey an idea. The idea maybe a business problem, or a social network site, or anything. At least for the web, everything has to spit out the final HTML. On the client side, Javasript does the user interaction. The there must be some data exchange between the client and the server. And the server part handles the calculation to again spit out more HTML. Everything .NET or Java is capable of doing, Cobol can also do it, only with more code and lots of efforts.
I believe that we are just talking about solving a problems in different tongues. Since no *sane* people would do web development in Cobol, we invent more stuff to make the job of the developer easier. We have .NET, Java, Python, Ruby, etc. From strongly to dynamically typed, the point is to make the developer more productive and effective at solving the problems at hand.
Since in the end, most languages are the same (talking about the same thing), now the different frameworks would be another story: which framework can help the developer solve the problem the fastest will be more likely to win. I would say there will be more frameworks providing more elegant ways to solve more difficult problems, with Rails pave the way for the next revolution of programming.
We developers have suffered too much from trying to talk in a foreign tongue and have to write poem in it. It can be done, but painful, costly, and slow. I just hate to see myself do the b*tchwork every single time just to be able to query the database and retrieve some rows. How many hoops do I have to jump within .NET to do so? While in Rails, everything can be a 1-liner. That is a huge different between using a light saber and a stone hammer to get the job done. For the mass of developers out here trying to make a living, the framework that allows them to finish the project the fastest with less pain will win. Be it Python, Ruby, Javascript, .NET, Java, or any other platform: does it matter? The most flexible framework using any of these languages will be the answer.