Scripting Gurus Debate Dynamic Languages

• By John K. Waters
• 05/16/08

Tim Bray, co-inventor of XML and Sun Microsystems' director of Web technologies, hosted a lively post-Script Bowl panel discussion on the future of dynamic scripting languages at this year's JavaOne Conference.

"Until a few years ago, the entire world was either Java or .NET," Bray observed. "And now all of a sudden, we have an explosion of new languages. We are at a very exciting inflection point where any new language with a good design basis has a chance of becoming a major player in the software development scene."

Angsuman Chakraborty, CEO of Taragana, a software development outsourcing company based in West Bengal, India, asked the panel what turned out to be a central question of the discussion: Why, in the midst of this explosion, when we already have such popular dynamic scripters as Python, Ruby on Rails and PHP, did the world need Sun's new scripting language, JavaFX Script?

"It's just one more thing to learn," Chakraborty said, "and with all these very similar languages, it becomes harder and harder for the developer to master each one."

Bray's answer, in a nutshell, was that no single language is going to solve everyone's needs. Also, JavaFX was aimed at content authors building rich user interfaces and using Flash, rather than traditional developers.

"The thought that there has to be one language for anything doesn't make a whole lot of sense," said panelist Tor Norbye, a principal engineer at Sun who works on the Ruby and JavaScript editors in the NetBeans IDE. "That's been the standard on the Java platform, but it's not the way people do development off the platform and in a lot of other application domains. JavaFX Script provides another way to do this, a way that's custom tailored to particular application domain, but not to the exclusion of other languages. It's the diversity of languages on the platform that we're trying to emphasize."

Ted Leung, principal engineer in the Dynamic Languages and Tools group at Sun, pointed out that this scripter explosion didn't actually involve many new languages. "A lot of these languages have existed for 10 years-plus," he said. "Before Java there was a profusion of what we now call dynamic languages that were about to come into the marketplace. Then Java happened and you had this sort of nuclear winter effect over all those languages. Now people are building software using these other technologies."

"For too long, we've tried to put developers into one box," added Greg Murray, Sun's AJAX architect and creator and principal architect of Project jMaki. "We've said if you're going to do this type of application with this platform and this language, you're going to do this other type of application with another type of language. But developers are individuals, and developer organizations have their own skill sets. These different languages provide multiple ways to approach problems."

To a question from the audience about why anyone would port dynamic language runtimes to the JVM, Charles Nutter, co-lead developer on the JRuby project and now full-time JRuby exec at Sun, said, "You've probably noticed that Python developers are rarely heavy Ruby developers, and Ruby developers are rarely heavy Groovy developers. It's not that any one of those platforms differs significantly from the others as far as capabilities. It's just that certain types of developers and certain types of problems are going to be well-suited to particular languages and platforms. Now, we're finally starting to recognize that, on the JVM, we can provide an excellent base for all of those languages and frameworks to run on."

Another attendee asked what's missing from the Java programming language that would make all of these dynamic languages so popular.

"One of the nice characteristics of Ruby, Groovy and Python is that they have a malleable syntax," said Guillaume Laforge, Groovy project lead and initiator of the Grails project, "and all those dynamic features bring new innovative ways of expressing your code in a more readable way. That's probably one of the key aspects of these languages that makes them sometimes more interesting to use for a given domain than a generally purpose language like Java. And it brings productivity to the process."

"Another reason that people chose dynamic languages over Java is less code," Bray added. "Dynamic languages frequently allow you to address the same problem in a third the number of lines of code. And code is nasty stuff. It's expensive to create, and bloody expensive to maintain, and the less of it you have the better."

To a question about why there are no implementations of these dynamic languages for the .NET CLR, Leung observed that Microsoft has, until recently, been language-focused.

"If you look at what Microsoft is doing in this space, you can see that." he said. "But we know from the success of the Java platform that it's more than just the language that matters. It's the surrounding libraries, the frameworks, and all that."

"The CLR kind of grew up on the static language side of the world, from the C++ folks," Nutter said. "Whereas Java grew up on the Smalltalk side of the world. It was actually grown out of a Smalltalk VM. So what we have on the JVM, oddly enough, is a dynamic language runtime under the covers powering a statically typed language. The work that we are doing in future versions of the JVM and the work that we're doing with JRuby and the current set of dynamic languages is essentially exposing that capability to run dynamic languages extremely well to all of the different language implementations."

Bray added that he didn't see great differences between the two. "I think it's a business issue," he said. "I think .NET is good technology, well-designed and well-implemented. That's a controversial statement to make around here. But what's not so controversial is that .NET comes from a troubling set of lock-ins and tie-ins. And that's the problem with .NET."

Chakraborty came away from the panel unsatisfied with the panel's answer. "Sun is focused more on getting all the languages under the hood so that they can get more of the developer base," he said. "But practically speaking, this amounts to unnecessary and even confusing diversity for the developer."