Programming languages and their environments are an abiding passion. I'm always on the lookout for a better mousetrap, and lately I've been working with three relative newcomers: the PHP-based plugin architecture of the WordPress blogging engine, the Ruby on Rails framework, and Mark Logic's XQuery-based Content Interaction Server. Each of these languages does very different things for different reasons, and the associated environments are likewise very different. But in each case the language is tightly bound to the environment in ways that I often wish it weren't.
...
Languages and environments have always been fellow travelers. At some point they'll begin to part ways. Domain-specific languages will continue to flourish; they're the future of programming. But they'll target fewer environments. The most obvious of these are the Java Virtual Machine and the .NET Common Language Runtime, along with their class frameworks. It'll take another turn of the evolutionary crank, but we'll get there. [Full story at InfoWorld.com]
In this column I give three examples of programming idioms that are tightly (and, I argue, unnecessarily) bound to programming environments. One of them is the object-relational mapper that's built into Ruby on Rails. I've only scratched the surface of this thing, but let's assume for the sake of argument that it's a brilliant framework. The column suggests that it ought not be necessary to write Ruby code in order to use that framework.
Yesterday I mentioned another object-relational mapper, Perl's Class::DBI, and said that my inability to quickly grasp how it worked led me to an alternate solution -- one that was PHP-based and, more to the point, was literal rather than abstract.
It's easier to learn languages than to learn environments. So while these things have tended to proliferate in pairs -- each language carrying around its own environment, like a turtle with its shell -- my argument is that over time the environments will tend to consolidate.
While environments may not need to evolve as rapidly as languages, though, they certainly need to evolve more rapidly than the Java and .NET environments do. That's why I've always been so keen to see dynamic languages integrate deeply with the JVM and CLR.
Jim Hugunin, who created first Jython and then IronPython, may be the world's foremost expert on this topic. When I met with him recently, I asked if he thought we'd see official .NET Framework classes written in IronPython. He said that, although dynamic languages will accelerate the development of the framework, extensions written in Python will likely be rewritten in statically-compiled languages for production use. To some dynamic-language advocates that may sound old-fashioned, but to me it sounds pragmatic.
Former URL: http://weblog.infoworld.com/udell/2005/04/05.html#a1208