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.
“We’ve seen the proof. JavaScript is a dynamic language, and it’s at the heart of a new breed of web applications”
By default. People wanted to build better web applications. Programming against Flash movies sucked. Javascript was already in all the browsers. If you’re the last man left on earth, it doesn’t matter how ugly you are when the women come to re-populate the planet.
Dynamic languages are much better glue than static languages. Especially with metaprogramming and reflective capabilities thrown into the mix. What would be interesting is to leverage a strong static programming language to build commonly used libraries that the dynamic languages glue together. Any idea if F# will be able to compile to Silverlight?
There’s more on the MIX07 “Jim Hugunin and John Lam Talk” at http://oakleafblog.blogspot.com/2007/04/stealth-dynamic-languages-presentation.html.
–rj
Vijay: I don’t see why F# couldn’t do so right now, assuming that it didn’t require additional libraries. If you dig even slightly into Silverlight (Hanselman’s recent post is a good place), you’ll see that it’s the same IL on pretty much the same CLR.
Silverlight has an amazing potential, but honestly, I wish it was another company that owned it. Microsoft simply has too much baggage in the cross-platform area, things like Rotor, the PRFest that is Port 25, or going back a bit, Active X on !Microsoft.
They have regularly trotted out their “new attitude” towards interop, and it’s lasted a version, if that long, then all of a sudden, it’s a Windows – Only technology. Usually, after they’ve seen enough sales in the dev tools to know that changing to a competing tech would be more than a little painful. The problem today is, that the people who made these earlier decisions are still, for the most part, running MSFT. So while the tech is cool, I can’t really take it seriously as a “universal” RIA until I see regular updates for *all* supported platforms, and a few years of it being fully supported.
Given MSFT’s past and outside of one rather small business unit, its management’s continual hatred of !Microsoft, trusting Microsoft MS to not act according to type is, IMO, irresponsible at worst, unrealistic at best, especially considering that the current management team is the one that made the earlier decisions.
(And no, I don’t particularly think of Ray Ozzie as the guy that will drag Microsoft into a brave new world of interop. I think of him as the guy who foisted Notes on the world, and as someone who has tried to both use and support Notes, I’m not terribly impressed with the guy who created groupware best defined as something you do *to* people, not *for* people.)
very interesting.
I just provided a bit of a rebuttal / posed some questions based on a sound bite from the podcast: http://www-03.ibm.com/developerworks/blogs/page/pmuellr?entry=structured_javascript
.
This is all great stuff; can’t wait to see and hear more about it.
“JavaScript arguably isn’t well suited to programming in the medium-to-large”
Oh yes? And guess why? M$ is arguably half responsible of this because of their arguably not very suited web browsers…
As for the other half, I should recognize that it’s simply inherent to the language been poor indeed.
you are in reality a excellent webmaster. The site loading velocity
is incredible. It sort of feels that you are doing any distinctive trick.
Also, The contents are masterwork. you’ve done a excellent process on this subject!
It’s enormous that you are getting thoughts from this paragraph as well as from our dialogue made at this time.