There is an emerging notion that there are really three cleanly separated platforms that will be contending for the enterprise over the next few years: Java, .NET, and LAMP/friends. Current mainstream thinking suggests that LAMP isn’t really a contender but that dynamic languages at least have a chance of riding in on top of the JVM or CLR.
But I’d like to consider some of Sam’s findings in working with Parrot in the context of dynamic languages on the JVM or CLR. Specifically, that using a common VM for multiple languages is hard; and keep in mind that Sam is hacking on a VM that is designed for dynamic languages, whereas the mainstream VMs are not.
As I was saying, initial thinking suggested that one of Jython, JRuby, IronPython, etc. would be the horse that dynamic languages would ride into the enterprise but I’ve grown away from this notion for a few reasons:
Rails is gaining acceptance with hardcore Java heads under the C Ruby implementation, not the Java Ruby implementation.
The LAMP stack is gaining acceptance at a rapid pace and in my experience, adding Java/.NET to a LAMP setup results in an impedance mismatch both in tool simplicity and quality of license / community.
The misconception that dynamic languages are useful only for “scripting” type tasks (e.g. gluing static language code together in controlled environments) is fading fast. It’s hard to find someone who will argue that Python or Ruby are incapable of being used as the primary language on large projects where these people were everywhere as early as a year ago.
Dynamic Language to Shitty Language bridge libraries give you the best of both worlds: a portable and efficient implementation of the language interpreter plus the mass of libraries that were developed under legacy runtimes (yes, I’m trolling now) like the JVM and CLR.
I’d much prefer to be working on the C implementations of these languages as opposed to the mainstream VM based ones. The JVM/CLR based implementations have problems: C extension libraries (are they even possible?), a lag in features from their mainline counterparts, less community involvement, and running atop mainstream VMs typically requires more resources than running atop the C interpreters.
Further, Java and .NET have licensing issues that create obstacles to adoption. The inability of Linux/BSD distributions to include the vendor implementations is a problem that neither vendor seems to be willing to budge on. The Mono and GCJ/GNU Classpath projects are moving in the right direction, no doubt, but it bothers me that in the end our best case is a situation where we’re running great languages on top of VMs designed for poor languages and have no participation from their original creators. That doesn’t really give me the warm and fuzzy about the future of dynamic languages…
Note that Parrot is a very different situation from the mainstream VMs. It’s being designed for dynamic languages, is licensed for the community, and probably won’t have the same issues with wrapping C extension libraries.
Getting to the point, I’d like to challenge the assumption that running dynamic languages on mainstream VMs is optimal / desirable in the long term. The existing interpreters have thriving communities, years of proven use, and a slew of C/C++ extension wrappers to even more proven libraries. They are already cross-platform and there’s bridge code for accessing the vast set of functionality that has been implemented in Java or C#.
The real question for me becomes, when will LAMP/friends gain legitimacy as an “enterprise class” platform and how quickly will that force the industry to re-evaluate optimal deployment models?