Environment, behavior, and scripting

When Chad Dickerson's column was mobbed by the Slashdot crowd, I was reminded that the role of scripting is still very much unsettled. I won't join that debate, because there are valid arguments on all sides. Scripting languages such as Perl and Python are more productive than conventional languages such as Java and C# — except when they aren't. Likewise, Java and C# are more robust than their scripting cousins — except when they aren't. This just isn't an either/or issue. We cling to the notion that developers need to master only one programming language, but this notion has never been true. The short list, nowadays, might be Java or C#, SQL, JavaScript, Perl or Python, XSLT (Extensible Stylesheet Language Transformation), and maybe a Unix shell language.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

These languages differ along two axes: environment and behavior. JavaScript, for example, is a powerful and dynamic scripting language that can in principle be used in almost any environment but in practice is most often wielded from within the browser, with which it has a special relationship. Perl, Python, and Ruby provide their own environments in the form of libraries (such as Perl's Comprehensive Perl Archive Network, or CPAN) that mix scripted and compiled modules. Java's environment is defined by its class libraries, as is that of C#.

Behavior differences begin with syntax. Usually, scripting languages are much more concise than their conventional cousins. As Ward Cunningham has pointed out, less clutter aids clear thinking. But the dynamic nature of scripting languages is what really sets them apart. Data structures need not be declared in advance but can instead be discovered on the fly. This iterative and exploratory process is, for me, the most compelling and yet least well-understood benefit of scripting.

Ideally that benefit would be available in every environment. Web services are helping a lot. Databases and application servers that offer SOAP interfaces make it easy to compose applications in script. But there's always been an urge for deeper and more direct integration. A stunning example of what's possible is Jython, which marries Python to Java. In Jython, you can work interactively with the Java libraries, and create applets or servlets far more concisely than in Java. That's possible because Jython is a complete Python interpreter written in Java — an extraordinary tour de force. As you'd expect, there are performance issues with this layered approach. What's more, a similar Herculean effort is required to marry another language to Java — an effort which, in fact, many have undertaken.

The Java virtual machine wasn't designed for dynamically typed languages. Neither was the .Net virtual machine, although at first it seemed so. When Microsoft began talking about the CLR (Common Language Runtime), Perl and Python were often mentioned. The .Net Framework would be available to scripting languages as well as to the core .Net languages. This was a great idea, for a couple of reasons. For .Net programmers, a scriptable framework would be a huge productivity boon. And for scripters, a standard environment (or two) would be a major simplification.

Scripting languages have been Balkanized. When you take up Perl or Python, you're not just adopting syntax that's convenient for some purpose. You're buying into a complete self-contained programming environment that recreates a host of common idioms more or less from scratch. Even though Perl, Python, and Ruby rely on the same underlying XML parser, for example, each provides its own bindings to that component — at considerable effort. The same holds true for database access, networking, date/time manipulation, graphics, and so on.

The people who create these bindings are heroes, and for years I've enjoyed the benefits of their (largely unpaid) work. But times change, and I don't think writing a complete set of support libraries for each scripting language will continue to be a worthwhile endeavor. The Java and .Net libraries are becoming standard infrastructures that should be reused, not recreated. Scripting languages can, and indeed must, push forward with innovation. Features such as Python's list comprehensions and Ruby's iterators are powerful constructs that can rewrite the productivity equation. Scripting languages are also wonderful proving grounds for idioms that might get baked into the next generation of common infrastructure — for example, Ruby's tuplespace, which is a kind of associative memory. If new languages didn't have to recreate the standard environment, such innovations might happen more often, and might be easier to adopt.

All this presumes, of course, that we can get robust support for dynamic languages in the Java and .Net run times. So far, the results are not encouraging. Jython, as we've seen, succeeds by the extraordinary measure of rewriting the Python interpreter in Java. In the .Net world, early efforts to make Perl and Python into first-class .Net languages ran aground. Both projects have now retreated to a dual-run-time strategy. Scripts can produce and consume .Net interfaces but rely on their own virtual machines, not the CLR.

Is there a better solution for these environments? The designers of Parrot, the Perl 6 virtual machine, think not and have struck out on their own. "Why not compile to JVM/.Net?" the Parrot FAQ asks itself. And it answers: "Those VMs are designed for statically typed languages." That's true, sadly. It's a question of priorities, and support for dynamic languages isn't high on the list for Java or .Net. If I could make one change to both of these environments, that would be it.