Take a minute and read Stephen O’Grady’s write-up, which starts at the Sun Analyst Conference, but says a bunch of things about Java and LAMP and related subjects. I’ve been thinking about this stuff almost all the time for the past year or so, so let’s take his ideas a bit further.

Stephen talks about “scripting communities”, but I suspect he wouldn’t object to me widening the focus a bit to LAMP (Linux, Apache, MySQL, Perl/Python/PHP), because that’s where a lot of the scripting-language action is.

And before I say anything more, please review that little squib over to your right; I work for Sun and I have lots of opinions, but I do not speak for the company on this.

LAMP · The text you are now reading, and the Web site it lives on, are the product of a pure LAMP software suite. Java was never really a candidate, even though I’m reasonably expert with it and use it for other kinds of things. No ifs, ands, or buts; LAMP was a better choice for me for a quick-personal-blogging-system project. First, I work faster in Perl than Java and I got it done quick; coming up on my third anniversary, the total programming time is still just a couple of weeks. Second, the results are good; the way ongoing looks and works suits me. Third, the performance is excellent; the site can soak up a slashdotting without breathing hard.

So one way or another, there’s 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 they’re in love with Ruby, or because there’s 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.

(Obviously, there will also be a ton of Java-based development going on, because there are lots of jobs where Java is the right answer, but that’s not what we’re talking about here.)

Since we’re a computer company, it’s a no-brainer that we ought to make our computers a friendly home for LAMP. Actually, I think we already do; I take my particularly-piggish perl & python scripts and whenever I can, I run ’em on my Ultra 20 on Solaris, because that combo smokes anything else I can get my hands on. After all, every single one of those dynamic languages has a runtime that’s just a great big honkin’ C program, and Unix is pretty good at that. But there is a problem: While there are a zillion industry benchmarks to measure your Java performance, I don’t know of any standardized way to characterize performance on typical LAMP apps.

So yeah, Stephen’s got a point, we ought to be a bit more proactive about figuring out how to characterize LAMP performance, and making it obvious that we’re good at that game and happy to be in it.

LAMP/J · Stephen pointed out correctly that more and more of us here at Sun are talking about Jython and JRuby and Caucho (as in, PHP on the JVM) and so on. But Stephen points out “There are a great many dynamic language developers who either won’t or can’t run a JVM, so a Jython or a JRuby that will run on top of one is not of interest”.

Stephen, let me turn that around. 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. And I think they could be more productive if they could work in Ruby or Python at least some of the time.

But they absolutely can’t or won’t not run a JVM, because that’s where their apps are. So to make their lives better, we should make sure that the right tools are there for them.

There’s another reason, too. The next big wave of server CPUs (starting with our own Niagara) are going to be increasingly multithreaded and concurrent. There’s no choice, we can’t just go on turning up the clock rate, so if you want more performance, parallelism is the way to get it.

At the moment, the threading in Perl and Python and Ruby and PHP tends to be amateurish-to-absent. Java’s 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 they’re starting from way behind.

So there’s potentially a big performance boost to be had in bringing at least some dynamic-language apps on board the Java platform.

What Should Sun Do? · A large part of the problem is simply the message. For years, the perception has been that the Java platform looks like this:

The Original Java Platform

I’d like us to end up with something that looks more like this:

The Future of the Java Platform

You still have all those APIs, you still have that nice fast threaded JVM, but you can work in whatever language you want to.

So the first thing we have to do is to stop mixing up the Java Language and the Java Platform, and make it clear to the world that other languages—in particular dynamic languages—work fine on the platform, and that there’s nothing wrong with using them.

Then we have to do some engineering work to help this happen. The good news is, we’re getting started on that; see Gilad Bracha’s article and slides on the JVM-level progress. But that’s way down in the engine room; I think we need to help out all the way up and down the stack; the profilers and debuggers and IDEs and, well everything.

But still (call me a marketing droid if you want to) I think the message is the important thing: It’s time to grow and share the Java platform; everybody wins.

author · Dad · software · colophon · rights

February 02, 2006
· Technology (77 fragments)
· · Dynamic Languages (45 more)
· · Java (123 more)

By .

I am an employee
of Amazon.com, but
the opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.