lesscode.org

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?

I’d like to advise everyone attending OSCON with an interest in dynamic languages to not miss Sam Ruby’s pie-thon Update:

OSCON 2004 was the home of the pie-thon challenge, which pitted Parrot against CPython on a test of speed using a bechmark that Guido van Rossum designed. This presentation provides an update–not only on performance, but also on language compatibility, as well as an outlook on the potentials for inter-language interop that can be acheived by a common language runtime for dynamic languages.

I was lucky enough to chat with Sam about this a bit and the little I got out of him was intriguing. The blurb doesn’t go into a lot of detail but one of things he’ll be talking about is compatibility between dynamic languages at the runtime level. Here’s a sneak peek:

<rubys>    There is a big difference between Python and
           Perl. Ruby might be someplace in between.
<rtomayko> that's interesting. I've been seeing reports of 
           the same thing from the CLR and JVM crowds
<rubys>    my favorite example: what does 
           """ print  '1' + '2'; """ do?
<rtomayko> ahh
<rtomayko> and so the strong/weak thing is down at that level?
<rubys>    it is not just that.  "+" is a function in Perl.  It 
           accepts two arguments which have types.  It coerces them 
           to numeric values, and adds them.
<rtomayko> python = '12', perl = 3, ruby = '12' (i think)
<rubys>    "+" is a synonym for "__add__" in Python.  It merely is 
           the name of a method.  What it does is up to the first 
           argument.
<rtomayko> right, I see. and so all of these languages will have 
           to shift a bit.
<rubys>    shifting all the language a bit is what .net did.  And 
           you end up with "Visual Fred" (look it up)

Visual Fred was the name proposed for Visual Basic.NET by MVPs who quickly realized that VB.NET had nothing to do with VB due to the syntactic and semantic changes forced on the language by the common runtime.

My time has been split between Rails/Django research and reading Andy Smith’s excellent Why Frameworks Suck essay/rant over and over. I can’t really explain that.

Once Django is launched-launched, I’ll be comparing various aspects of it with Ruby on Rails. I plan on diving deep into the two frameworks so instead of one large post, I’m going to make this a running series.

While I’m primarily a Python coder, I’ve been dabbling with Ruby for about a year and have a couple of apps under my belt with Rails. They are admittedly simple apps but what isn’t with Rails? I’ve also logged 70-80 hours against a Python clone of Rails’ excellent implementation of Active Record, which put me pretty deep into the internals of that piece.

I am not a Python zealot. And, to be honest, I’m floating between the two languages as my primary. What I’m trying to say is that my interest is in exploring these two frameworks objectively and extending my understanding of each, not advocating one over the other. I will include personal thoughts on design and may favor one or the other at this level but I will not be concluding the series with a recommendation for either because, frankly, I already know which I’d recommend at present and it has nothing to do with technical qualities (hint: it has everything to do with this).

That being said, I can recommend that if you are building systems that require the complexity of a full-stack web framework (i.e. PHP, CGI won’t cut it) and you are currently using something other than one of these two frameworks in any language (including Java and .NET) on any platform, that you move swiftly to adopt either if possible. If there is something barring you from making that switch, well, where’s your patch? Make it happen.

I realize that many in the Python community have already grown comfortable with an existing framework (or more likely, have written their own, like myself) and that’s fine as there are some competent frameworks out there. But it has become apparent that Django will be growing a large community of contributors and that’s something no current Python web framework of this kind can boast.

As I write this, there are 30 people idling in #django on irc.freenode.net on a Sunday morning, two days after the none-launch; there’s been 409 bookmarks on del.icio.us. Granted this is all very much driven by hype right now as there hasn’t been any real experience with the framework, excepting the maintainers, but the outlook for a large community to finally coalesce around a single set of tools and conventions is promising.

I also want to mention that I spent some time talking to the Django maintainers last night and they’ve convinced me that the Rails comparisons, while unavoidable, may be somewhat premature. Although Django has many of the same traits as Rails, it wasn’t built as an all out clone and may appeal to a slightly different set of requirements. Time will tell, of course, but as of right now the similarities are a huge part of what’s driving interest in Django and there’s a good reason for that - Rails got a ton right.

Still, “because it’s in Rails” is unlikely to be considered sufficient justification for Django feature requests. That’s a sure way of creating a Bride of Frankenstein framework and I’m pleased to see the maintainers have a strong sense of this. Django is likely to follow many of the same paths as Rails but that’s because they were both designed under real life circumstances with similarly excellent philosophy.

Before I wrap this up, I’d like to echo the sentiments of one Rails supporter in his comments on Django:

I hope Rails learns to play with Django and they’ll not smite each other (if not friends, don’t be enemies). The world is big enough. A combined message from different camps will be more resounding than any one camp trying to say he is the bestest - and coming off as naive or clueless.

Indeed.

(warning: stomach wrenching, KUM BAI AH, everyone-hold-hands type stuff imminent)

The Ruby, Python, Perl, and PHP communities must understand the immense opportunities that await them should they accept that they share much more in common than not and that a unified front would go a long way in tearing down the barriers that have kept these technologies out of the mainstream. The amount of positive impact these disruptive technologies could have on existing forms of business and social interaction in general are limited only by our ability to tell the story.

Feeds for the series:

• RSS2
• Atom 0.3

A colleague of mine had suggested on numerous occasions that I read the book, “Guns, Germs, and Steel“, by Jared Diamond. Wherein the author explains that the rise of Western civilization was due largely to a series of lucky developments that turned out to be so disruptive when introduced into other environments that there was just no chance of their old ways surviving.

Tim O’Reilly recently pointed to a bout scheduled for this years OSCON where Byron Sebastian, CEO and Founder of SourceLabs, will go toe to toe with Bob Sutor, VP of Standards at IBM Corporation, on whether F/OSS is to the Enterprise as Guns were to the Incas.

The format is interesting with Sebastian taking the extreme position of “open source takes all” and Sutor the position of “protracted struggle between proprietary and open source enterprise software”. It’s interesting to note that they couldn’t find anyone to champion the “proprietary takes all” scenario.

I’m not able to attend this years OSCON but I’m hoping this debate makes it’s way onto IT Conversations. If anyone attending wants to live blog the debate for lesscode.org, it would be much appreciated.