Speaking of Programming Languages

Are PHP, Ruby, and other languages a threat to Java? Is there room on the platform for the others? See what experts said about programming languages at the 2006 Java Technology Roundtable.

Though JavaOne and concurrent ancillary events like the Java Technology Roundtable are primarily all about everything that is Java, the Java programming language is clearly not the only kid on the block. Languages like BeanShell, Groovy, PHP, Python, Ruby, and others are making tremendous headway on the Java platform, and the subject of whether or not they constitute a threat to the Java language was discussed at some length by the panel of industry thought leaders at the 2006 Java Technology Roundtable to kick off the second hour of the event.

Java, the Language
Simon Phipps: Welcome back after the break. Just as the conversation was getting exciting there, I pushed you all apart so you couldn't engage in barbaric, hand-to-hand combat. Some of the discussion there was beginning to veer in the direction of programming languages. I'm interested to know whether Java is it. We've talked about the second wave of the Java platform. Is the second wave of the Java platform going to be programmed in Java? Is Java doomed and about to be replaced by something that is more appropriate? Is there a place where other programming languages are going to run on the Java platform, and does anyone care in an era of drag, drop, and deploy? So what do you think?

Tim Bray: I want to go back to Smalltalk.

Phipps: So does Mike.

Bray: Smalltalk is coming back, you know. C-side framework is in all sorts of deployments. We had a really interesting session at JavaOne yesterday. We had three 10-minute dissertations. One was from a company [name mispronounced] that had this thing [that] had PHP passed [as] bytecodes and runs faster than native PHP on the JVM.

Frank Cohen: Querzo.

Bray: Quercus, q-u-e-r-c-u-s, right? Then there was the JRuby guys who have got Rails applications running on the JVM now, and they also had part of an interactive Ruby shell and typed Swing stuff into it and got a thing with a button to pop up and so on. Third one was a presentation from Phobos, which is an internal Sun gunk works, which is doing, brace yourselves, server-side JavaScript on the JVM, and it's building Ajax applications for all the code on both sides in the same language. Once you get over the initial shock, it looks kind of seductive. So without offering any opinions, I offer that by way of, sort of, evidence relevant to Simon's questions.

Phipps: Larry, you're itching to say something.

Larry Cable: I'm itching to say something. I think the greatest thing since sliced bread for the budding language designers of the world is the Java Virtual Machine, because basically we've taken all of the boring parts of building and developing new programming languages out of their hands and given them a platform in which they can build languages that do whatever they can imagine and deploy it on the Java platform. They don't have to go to all of the trouble of spending three years writing a C-based interpreter, dealing with memory management, integrating with the underlying operating system functionality. They generate Java bytecode, and they're done, right? This is a great opportunity for everyone in this room to invent their own programming language.

Phipps: But a Web page I've been linking to ever since I've been able to link Web pages is Robert Tolksdorf's "Programming Languages for the VM" Web page. There's been 200 programming languages that run on the Java VM since time immemorial, to most of the current generation anyway, and yet no one uses any of them. Why is it going to be any different this time around?

Cable: I think it's going to change because vendors like BEA… Graham Hamilton stood up yesterday and basically drew a diagram on the board that says he wants to go out and embrace new developer communities, and I think that's going to be the driving force as we want JavaScript on the server side, we want PHP on the server side, dot, dot, dot.

Only the Beginning
Cohen: There is an important thing to keep in mind when you're evaluating whether the scripting languages are good for the VM, in that not all of them compile to bytecode. As a matter of fact, most of them don't; they're still interpreted.

Phipps: But BeanShell is interpreted; being interpreted doesn't mean you can't use the VM.

Bob Blainey: It's not a question of being interpreted or not, it's a question of using the JVM interface.

Sam Pullara: I'm a committer on the Groovy project, and you might have seen that people have proposed a JSR around an invoke dynamic. That was an idea I had two years ago when I started working on it, but after looking at all the languages that have come out, more and more I think it was probably a bad idea because not everybody has the same dispatch policy. It's very difficult to take the way Ruby invokes Wilkes methods, and the way Python does, and the way Groovy does, and the way Java does, and put them all in this one instruction. And then further I've seen that if you think about it you can compile that bytecoded dynamic language through, especially if you have HotSwap, in such a way that you can optimize these things. I don't think that's going to be a big issue.

The big issue—whether or not Java is the last language or not—is that first of all Java is a moving target, and, no, Java 1.5 is not the last language. What Java is changes yearly. So I think that that's a big advantage for it, in the sense that, yeah we might still be using something called Java years from now while most … people [will] be maintaining it, but we may be programming new code into it as well. It may not be your father's Java, so to speak.

One of the things that I used to say when I was at WebLogic, and we first started there, is even in '96 we thought, "you know what, maybe this is the last thing, and if there is another thing it's going to be Java with versioning because that's the only thing they left out." And then you know I was on the module JSR, and I was OSGi, and maybe we will even have … versioning and package in the language, in 1.6, finally. Maybe we are able to evolve it forward, and eventually you'll either program in Java and you're a systems programmer or you drive and drop stuff, as someone once said. Maybe there doesn't need to be an in-between.

Blainey: Well, I think it's crazy to think it's the end of languages, and clearly it's not. You can survey the 10 or 11 years of Java, and you've seen that there's been many new languages invented—I would say sort of shockingly fewer than the prior generation because I think new languages are fantastic—because it's the way that people creatively think of mapping abstractions on a machine, whether they are a new systems programming language or a new general-purpose language or a domain-specific language for business process, for linear algebra, or whatever your problem set is.

I think that this is a great thing, and I agree with what Larry is saying. I think that the JVM is one of the great enablers of that. Now the fact that few people have adopted the language that has been done primarily for research purposes on top of the JVM is not really the point. I think that a lot of creativity has happened, and because you've factored out some of the hard bits—I wouldn't say the boring bits—then you've made the creativity that much better. However, I think that there's a lot that could be done to the JVM; learning from the CLR, for instance, and generalizing it and making it more appropriate for multiple languages would just make it that much better.

Language Seduction
Bray: One reason those languages have not been widely adopted is because a lot of influential people kind of sneered at them. They really did have the feeling that Java was all you needed. Now, for those few guys who have not been to the mat with Python or Ruby, you really should. They are qualitative, large qualitative steps forward in productivity for certain problem domains. Python is great. Ruby is beyond great. Ruby is just absolutely, seductively wonderful.

Pullara: But it's older than Java is.

Bray: That's true.

Jon Bostrom: Well just one comment from the mobile side is that you have to look at the proliferation of Java into a billion plus devices, and that's not going to go away. I mean all the manufacturers are continuing down that, and with the steps forward that we're making… We're finally, you know, we're on the verge of getting SOA on the mobile device, with JSR 232. Think about the idea of middleware coming down to a mobile device. We've never had that. We've had a single monolithic application model with MIDP, and look how far we've gotten. When we now bring this in and we open up this whole middleware space with services on the mobile platform, and those services can then be run underneath the hosted languages whether it's a scripting hosted on a VM or Java widgets on a VM, or whatever, it opens up a continuing path for two billion and three billion devices that are going to have this out there. It changes the landscape.

Rob Gingell: Yeah, but the thing those billions of devices have isn't actually Java it has the bytecodes, right, because it's really packaging the VM. And that was always the cool thing about Java is that it divided the problem into a set of expressions and then the mechanism for executing them interoperably, and the interoperable execution was when all of the compatibility stuff was always designed into that. It wasn't always about maintaining the absolute syntax of the language in some sense; it's about enabling the common run-time environment that is the thing that's going to be really durable. I also agree, to our previous discussion, examples of bad tools are maybe this leakage notion that tools really are trying to be other languages that are trying to hijack the concepts and redirect them to some other purpose, rather than simply inventing a language suitable for this.

So we make the physicist now do complex dot blah, blah, blah, and they're just being driven nuts by typing all of this stuff. And things like the IDEs and tools that help you scale, right—and you gave the idea of the card catalog—that's to me the epitome of IDEs because we have search engines to make the Internet usable because otherwise we'd never find anything. You have card catalogs to make libraries usable, you have IDEs because the volume of classes you have to address simply defies things. And that all works for scaling; where it runs into brick walls is if you really wanted to say something else. Then the domain-specific language shows up, and the reason those 200 haven't worked is it's harder to write a good one than it is to write a bad one. So there'll be a lot of chaff with this one.

Fight'n' Words
Ari Zilka: I think what we've ignored thus far in the discussion, that would add some clarity [to] the whole notion of governance and IT's influence over dev and dev's influence over IT, is we're ignoring the hardware deployment model separate of the programming language. At the end of the day we've got two comments flying and have collided with each other: Java, JVMs, development in this object-oriented fashion, AOP, and bytecode manipulation taking things to further and further layers of abstraction, and at the same time smaller and smaller machines where if I lose one, I lose one one-hundredth of my capacity. Our new definition of the business platform, from an IT perspective, [is] they don't care how dev writes the code that runs on the machine. What they care about is that it's a lot of plug-and-play blades, and that's what they care about right now. The JVM, exactly like Larry is saying, makes it easier for people like us to get in and help developers spend their time in the language and solve business problems and not deal with IT's demand for making these five machines work together as one. And so the abstractions are very powerful.

Ted Farrell: Yes, I think the multiple languages are good for the VM, and I think there's a class in the scripting world and the .NET, the Microsoft world, that are looking for something small and quick. But you know I've never talked to an enterprise customer who's said, "You know, I love the tech stack but can you give me more languages?" I think the only reason we moved to Java is because the platform changed, and the actual runtime changed. I do think Java's here for a long time, and I agree with Sam, and you to a certain extent, and I think it will evolve and we can add more abstractions on it to help describe it in a higher level. But I do think as for that core thing it's going to have to take something big like a new platform change to get people to go through this again. I think there will always be sort of the outskirts fighting for the different types of scripting languages and fun kind of languages, but…

Pullara: I think it's for better for worse.

Mike Milinkovich: Let's face it, Java is the COBOL of our generation.

Cable: Take your glasses off. Them's fighting words, mister.

Milinkovich: Why do people think that's a bad thing? COBOL defines a safe technology choice for an entire generation of programmers. Just like eventually COBOL gives way, the idea that Java will never give way to another language…

Phipps: Have you not used Object COBOL? [laughter]

Milinkovich: I'm sorry, my last COBOL was something like '72.

Cable: Invoke method on object with parameters given…

Milinkovich: Did they have an object section or something?

Bray: Let's be fair to Java. The Java language, not the Java EE, but the Java language has two big advantages over all the upstarts. One is static typing, much as all of us may sneer at it, [that] gives the IDE a lot of help. You know they're building good stuff for Eclipse on those other languages. The kind of refactoring and autocompletion support in Java, it's just way better because it knows where everything is as soon as it sees a variable name, or even the beginning of a variable name. And the second thing is, one of the great things about dynamic languages is the duct taping. You know, you say here's something I'm going to call this method on it, right, and at compile time, yeah, okay, there might be a method there and there might not. In Java it's basically a jump to a binary offset in the JVM because it knows at compile time exactly what's what.

Most   Popular