On the Friday before MIX, I recorded this podcast with John Lam. He’s the creator of RubyCLR and, as it happens, he joined Microsoft on the same day I did. John’s been running silent since then, but no longer. In this conversation we discuss the dynamic language runtime (DLR), a generalization of Jim Hugunin’s work on IronPython, and a quartet of languages that make use of its services. They include a refactored IronPython, a new managed implementation of JavaScript, Visual Basic, and a new implementation of Ruby which, unlike RubyCLR, does not rely on the C-based Ruby runtime.

We also explore the ability of these languagues to run inside Silverlight-equipped browsers. Key benefits include cross-language interoperability, access to Silverlight’s subset of the .NET Framework, and more broadly, a new approach to writing ambitious browser-based software.

Among other things, that approach restores and reinvigorates a capability that’s been around for a decade. I can well remember, back in the day, running ActiveState’s Perl as a scripting engine inside Internet Explorer. It made for an interesting demo, but I never wound up using it for anything and I never heard of anyone else who did either. In retrospect I think there were two reasons why. First, the notion of running serious amounts of software inside the browser hadn’t taken hold. Now it clearly has.

Second, it’s risky to deploy a standalone language runtime — like Perl’s, or Python’s or Ruby’s — inside the browser. But the Silverlight languages are nicely sandboxed because they ride atop the dynamic language runtime, and it doesn’t rely on any privileged operations.

The DLR-based version of Ruby isn’t quite ready, and it doesn’t yet run Rails. That’s the acid test because, as John says, Rails uses every metaprogramming trick in the book. But the intent is to get it working, and I think that’s the kind of thing that’ll open up possibilities nobody can fully predict. The AJAX model has succeeded despite the fact that JavaScript arguably isn’t well suited to programming in the medium-to-large. DLR-based implementations of Ruby and Python should be better suited to that purpose. What’s more, in this environment they can not only interoperate with each other — so you can use a Python library directly from Ruby, or vice versa — but with statically typed languages like C#. So they can leverage capabilities that depend on static typing, like LINQ (language integrated query).

It’s hard to talk about a topic like this without sounding hopelessly geeky. “Look, I’ve got IronPython using ActiveRecord and LINQ, all inside the Safari browser on my Mac, and I’m debugging it in Visual Studio remotely from my PC.” These kinds of scenarios are in fact becoming possible, and those of us who appreciate all of these components individually will rightly pronounce it cool that they can come together in these ways.

But it’s more than a parlor trick, though it’s hard to explain why that’s so, or why anyone other than a code monkey and dynamic language junkie should care. In view of that challenge, I referred at the beginning of this podcast to my interview with Avi Bryant and Andrew Catton about Dabble DB, which is built on top of the Squeak implementation of Smalltalk. Dabble DB surfaces the virtues of the underlying dynamic language engine — direct manipulation, always-live data, continuous refinement — to people who create and use Dabble DB applications. Yes, dynamic languages can make programmers more productive. But when used properly, they can also produce software that makes everyone more productive for the same reasons.

We’ve seen the proof. JavaScript is a dynamic language, and it’s at the heart of a new breed of web applications that make things easier for everyone. I hope that expanding the range of dynamic languages available in the browser, while at the same time basing them on a common runtime, will accelerate the trend.