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.

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.