Dynamic languages for agile enterprises

At the 2004 Open Source Convention (OSCON) in Portland, Ore., Jim Hugunin, the creator of Jython, made the dramatic announcement that he would be joining Microsoft to pursue his latest project, IronPython, a Python implementation for the .Net CLR (Common Language Runtime). The timing was awkward for OSCON -- nothing chills the room like news that an open source hero is emigrating to Redmond -- but it was opportune for me. I had just written the keynote talk that I would deliver a few days later, at the Vancouver Python Conference; it ended with a plea to consummate the marriage between popular dynamic languages, such as Python and Ruby, and the dominant managed runtimes, namely the JVM (Java Virtual Machine) and the CLR.

Recent weeks brought important news on both fronts. On Sept. 5, IronPython 1.0 was released to CodePlex, Microsoft’s community development Web site. As demonstrated and discussed in Episode 8 of The Screening Room, the purpose of IronPython is not to compete with statically typed .Net languages such as C#, but to complement them.

Then on Sept. 7, Sun announced that it had hired Thomas Enebo and Charles Nutter, maintainers of JRuby, the JVM-based Ruby implementation, to continue their work on that project. That’s two great strategic moves rolled into one.

First, it’s a bid for peace between two warring camps. Users of the wildly popular Ruby on Rails framework have had nothing good to say about users of enterprise-grade Java frameworks, and vice versa. Once a solid bridge is built between the two, this pointless bickering can end.

Second, it turns up the heat under Sun’s initiative to make the JVM a better platform for languages other than Java, and in particular for dynamic languages. Gilad Bracha, Sun’s “distinguished engineer and computational theologist” who is driving the JVM in this direction, uttered the most widely cited sound bite: “It has come to our attention that some people want to program in things other than Java.”

Although I’ve been beating that drum for years, it’s been a struggle to elaborate usefully on Bracha’s quip. But now the picture is finally coming into focus, and Steve Vinoski, a middleware expert at Iona, has proposed a mnemonic to help keep things in focus: ECS STRTE. You’ll have to squint really hard to read that as “Easy Street,” but I intend to try.

ECS stands for Enterprise-Class Software, and STRTE stands for Software That Runs The Enterprise. ECS lives near one end of the tolerance continuum, where the relevant “-ilities” include reliability and scalability. In this realm, languages want to be statically typed and Web services want to be SOAPy. STRTE, characterized by simplicity and agility, lives near the other end, where languages want to be dynamically typed and Web services want to be RESTful.

Can’t we all just play nicely together? At the risk of sounding like a Pollyanna, perhaps we can. At InfoWorld’s last SOA Executive Forum, Vinoski shocked the audience by suggesting that it can sometimes make sense to write Web service implementations in JavaScript, as is now possible in Celtix, Iona’s open source enterprise service bus.

This week’s flurry of news about dynamic languages and managed runtimes helps make that notion less shocking, and it brings us two steps closer to detente. Why argue about dynamic versus static languages when you can have the best of both worlds?