Back when .Net was Microsoft Corp.'s shiny new replacement for boring old Java, the Redmond rhetoricians used to make a couple of points with which I heartily agreed. First, your platform ought not be joined at the hip to a programming language. Different people use different languages for different reasons; it's wise to accommodate them all. Second, dynamic (aka scripting) languages were going to be a .Net priority. Perl and Python, for example, would be compiled for native execution on implementations of the CLI (Common Language Infrastructure) -- that is, on Microsoft's Common Language Runtime, and now also on Microsoft's Shared Source CLI ("Rotor") and Ximian's Mono.
But when ActiveState tried the experiment, it didn't go well. The CLI is, by design, not friendly to dynamic languages. Prototypes were built, but ran way too slowly. So ActiveState attacked on the Perl front using a different strategy. Its PerlNET technology bridges the existing Perl interpreter to the .Net environment. You can use it to manipulate the .Net Framework from Perl and, even more impressive, to write Perl modules that appear as .Net components.
Now Brian Lloyd, engineering vice president at Zope, has taken a similar approach with Python. I've been trying out his experimental PythonNet, a bridge between the Python interpreter (Version 2.2) and the .Net environment. Thanks to Python's interactive style and its lovely introspection feature, this is a great way to spelunk around inside the .Net Framework.
Savvy Java developers will instantly think of Jython, which is a Java-based implementation of Python. Jython goes farther than PerlNet or PythonNet, though not as far as I hoped dynamic languages in .Net would go. Sean McGrath, CTO of Propylon, has called Jython "the most compelling weapon the Java platform has for its survival into the 21st century." What would justify such a remarkable claim? For starters, Jython speeds up learning how to use Java libraries and frameworks, as PerlNet and PythonNet can do for .Net components and the .Net Framework.
Scripting can drastically accelerate writing tests that exercise native Java or .Net software. So far, this has nothing to do with actually deploying a system based on a dynamic language. But once you've got a strong safety net of tests, you may find yourself reconsidering whether only Java or C# can implement your production system. Performance and robustness are the factors usually cited.
When the industry decided that J2EE was the standard for enterprise systems, we made a collective decision to regard VMs (virtual machines) as capable of mission-critical performance. Need to scale? Throw more VMs at the problem. Since dynamic languages aren't yet native citizens of the Java and .Net VMs, we don't yet know if that combination is a performance killer. We do know that impressively large systems run well on the Java and .Net VMs, while others do well on the Python and Perl VMs.
What about robustness? In a world where computation lived within a single VM, strong type-checking and bytecode verification may have been reasons to prefer languages such as C# and Java. But we don't live in that world any more. Computation is distributed; interfaces are language neutral and document oriented; cross-domain trust is a work in progress. In these circumstances, dynamic languages -- which neither the Java nor .Net VMs yet fully embrace -- may be the best way to tame the services network we are now constructing.