If you’re setting out to create a shortlist of people within the industry who are qualified to speak credibly on the future of application development and dynamic languages, it’s pretty fair bet that Sun’s Tim Bray is going to be on it (the decision makers at Sun are well aware of this, for those that are curious). Forget that he’s behind one of the more important infrastructure enabling technologies of the present (XML); his appreciation and understanding of dynamic languages is second to none. Much like Adam Bosworth, Tim is one of a handful of EF Hutton technologists – when they talk, I listen. Closely. All the more so when he’s talking about something I’ve written.
The piece that started this dialogue dealt with my reactions to the Sun Analyst Conference. Distilled to its essence, my point was that while Sun’s righted the ship on multiple fronts – the Solaris operating system, their x86 business, etc – they remain heavily Java preoccupied in a world that is increasingly seeking alternatives. Which alternatives? I’d intended the piece as an argument on behalf of dynamic languages, despite the fact that he caught me – in error – using scripting communities interchangably, but he wants to expand the argument to the much broader LAMP stack. Makes perfect sense here.
Anyhow, Tim wins immediate points by avoiding the typical Java/.NET responses to questions of the LAMP stack – responses that typically attempt to characterize LAMP as intrinsically unsuitable for anything other than the most trivial implementations. Instead, he acknowledges that LAMP is both a credible and popular platform, saying:
So one way or another, theres gonna be a lot of LAMP out there. Because people think they can get it done quicker, or because they know those P-languages better, or because theyre in love with Ruby, or because theres some library they want to use that only PHP has, or, well, who cares, there are a lot of reasons. Nothing we at Sun can say will change this, nor should we want to.
With him so far. From there, he argues on behalf of Sun’s dynamic-languages-on-a-JVM stance on the basis of three main contentions:
- First, that JVMs are common, maybe ubiquitous:
It turns out that most software developers spend most of their time, not building new green-field projects, but enhancing or extending or fixing existing apps. And most of those apps are on the JVM.
I’m not buying this entirely – more on that in a bit.
- Second, an assertion that threading is increasingly important in application development:
The next big wave of server CPUs (starting with our own Niagara) are going to be increasingly multithreaded and concurrent. Theres no choice, we cant just go on turning up the clock rate, so if you want more performance, parallelism is the way to get it.
Almost entirely agree with this; even laptops have dual cores these days. Plus, as I’ve argued before, scalability is more and more important. But is the need as universal as is implied here? Maybe not.
- Third, that with respect to scaling, the dynamic languages are, if not poor, inexperienced when compared with Java.
At the moment, the threading in Perl and Python and Ruby and PHP tends to be amateurish-to-absent. Javas threading/concurrency machinery, on the other hand, has been excellent for years, and got a lot better in the 1.5 release. The dynamic-language guys will be working on this, but theyre starting from way behind.
While I’d tend to defer to Tim’s greater experience in this area anyhow – threading was not one of my primary concerns as a developer – his comments mostly align with what I hear from both dynamic language and Java advocates.
Extrapolating from the above, Tim advocates a world that looks like this as opposed to this. A world, in other words, that leverages the JVM’s threading and concurrency skills and the dynamic languages’ productivity.
Personally, I’m not against this. Nor am I against Java. If you don’t buy that, I suggest you go read this piece I wrote a while back. But neither do I find the prospect of PHP, Python or Ruby on top of a JVM as compelling as Sun apparently does. There are a couple of reasons for this:
- Ubiquity:
Bray contends, as do many Java advocates, that JVMs are virtually omnipresent in development environments. To the extent that we’re talking about purely corporate development, that’s more or less a reasonable assertion. Excepting pure Microsoft shops – which in my experience are rare – Java’s the clear development language of choice for most corporate development. PHP’s made gains inside the firewall, as the IBM and Oracle partnerships indicate, but to borrow Tim’s words – there’s gonna be a lot of Java out there.But I’m just as interested in what happens outside the firewall – the individual developers building blogs and wikis and forums and feed readers and a host of other ‘non-enterprise’ apps on borrowed or hosted infrastructure. And that, IMO, is an area where Java’s anything but ubiquitous. For example, I did a quick and utterly non-comprehensive (meaning – correct me where I’m wrong) survey of some of the larger web hosts out there (as qualified by Netcraft) and discovered that while all ran PHP, Java coverage was spotty. A quick rundown on which hosts support Java out of the box:
- 1and1: No preinstalled Java
- GoDaddy: A Google site search turns up some Tomcat related information, but it doesn’t appear to be mentioned in the functional description of any of the servers nor in the configuration process
- Verio: Supports JSPs and servlets on Managed Private Servers only
- Rackspace:No, the list of installed software is this:
- Apache
- BIND
- GCC
- MySQL
- OpenSSH
- OpenSSL
- Perl
- PHP
- PostgreSQL
- Python
- Sendmail
- Webmin
- Interland: Yes, on their virtual private server package
The point of all of this? That contrary to its first class status within the enterprise, for individual developers working off hardware that’s not their own, the simplest path forward is what’s universally present: one of the dynamic languages. Java may or may not be available, and when it is, usually only on the higher end $40-50/month on up packages.
Many folks hosting their own blog infrastructure have faced this precise scenario; when contemplating a switch off of Movable Type the other day, Roller was suggested to me as a worthy alternative. But while I have the utmost respect for Dave Johnson and the rest of the Roller team, I have no intention of installing a JVM instance when PHP is already sitting right there for me.
So while I don’t really buy Tim’s argument that there’s always going to be a JVM available, it depends heavily on the context of what kind of development we’re talking about. I tend to think of JVM’s vs PHP in the context of the analogy that Oracle sometimes uses against MySQL; Oracle’s a 747 to MySQL’s Toyota Corolla. The 747 is undoubtedly more functional, but there are a hell of a lot more Corollas then there will ever be 747s.
- It Looks Like A Dynamic Language, But Is It?:
If we assume that Tim is right, however, and that JVM’s are both plentiful and a net benefit in their thread handling, would there be any reason at that point not to a JVM based dynamic language? I think so, and so – apparently – does one very bright developer. Here’s what Mr. Sequeira has to say on the matter:I’ve done a couple successful jython projects (Intraspect used it for it’s API), and it was definitely better than having to do low-level Java or suffer learning a proprietary scripting language.
However, I became quite frusted with how running language A on runtime B broke a tool I rely on to be a productive programmer: google. You can no longer reliably use google to find source code examples for doing things like parsing XML, say, because you’re now using a strange language that needs to call non-native class libraries. The native libraries no longer work, so neither does google or that stack of O’Reilly books sitting behind you. That realization really tempered my enthusiasm for the J* languages (and the Iron* ones).
Despite the best efforts of the folks behind JRuby, Jython and the like – it’s simply not the same as working natively. Can it be done? Certainly. Is it without its own set of issues? Doesn’t seem that way.
- Scalability?:
It’s going to seem like I’m contradicting myself here because I’m going to argue that scalability – and the related technical issues like threading – are not a huge issue for lots of developers when I’m on the record as saying that it’s a big issue today. But again, it’s a matter of context. If I’m designing a public web application, for example, am I concerned with scalability? You bet. But let’s look at something like Movable Type. Is the threading model for it of particular – or indeed, any – importance to RedMonk? Not really. We use it to spit out a bunch of static HTML pages which serve pretty damn fast with no help from either PHP or Java (it would admittedly be different if we used the dynamic capabilities). And yes, BTW, we are paid users of the product.So the point is not that Tim doesn’t have a point – he clearly does – but rather that there are and will continue to be a great many development challenges that are not likely to benefit immensely from the JVM’s superior thread handling abilities.
What then do I conclude from all of the above? Well, despite my concerns about Sun’s policies in this area, I think Tim is mostly correct: there are an increasing number of scenarios in which having the ability to run a dynamic language on top of a JVM would be highly desirable.
What would concern me, however, if I worked for Sun – and they are a client of ours – is that competitors such as IBM and Oracle are not forcing their developer base to make that choice. They are instead supporting them in their native environment, with no JVM involved at all. This is important because it’d be my contention that Sequeira is far more representative of the average developer than the folks at Sun would like. In short, I’d recommend that Sun support both JVM and native execution of dynamic languages. I think it’ll take some organizational change to get there – organizational change that Bray would be very happy with, I believe – but I’ll talk more about that another time.
Disclaimer: Sun, as mentioned is a client, as is IBM. MySQL, Oracle and Six Apart (Movable Type) are not. We are, however, paying clients of Movable Type. Of the mentioned web hosts, we’re a paying client of 1and1, but have no relationship with any of the others.
