Microsofts Dynamic Language Leaders Speak

Microsofts Dynamic Language Leaders Speak
( Page 1 of 2 )

Q&A: Some of the folks behind Microsoft's dynamic languages push take time to chat with eWEEK about their efforts.Microsoft has released a new Dynamic Language Runtime to support various dynamic languages running on the .Net platform. eWEEK senior editor Darryl K. Taft spoke with Microsoft dynamic language gurus Jim Hugunin and John Lam about the effort.

What can you tell me about the Dynamic Language Runtime and where it came from?

Hugunin: Where this all came from is I joined Microsoft with IronPython, but I joined to make the CLR [Common Language Runtime] a better platform for dynamic languages. In some ways this is what weve been working on for the past two and a half years. The way that we did that is we started by building one real high-quality production implementation of a language, which was IronPython, and getting a lot of users to beat on it and make sure that we could do it well. Now that we have that one quality implementation we started saying, Well, how can we make more languages run well on the platform and make them run even better?

So the idea of the DLR is to support a broad spectrum of languages building on what weve learned already. taking all the things in the CLR… IronPython runs well in the CLR because its got great things inside it, like really excellent GC [garbage collection], JITs [just-in-time compilation], excellent type system that you can work within, debugging, profiling, sandbox security model – great features that make it easy to build a language on top of it.

When we built IronPython we found that there were specific things to a dynamic language that we had to re-implement. So we had to re-implement, for the dynamic parts of Python, we had to build a Python type system on top of it. For the parts of hosting a scripting language, we had to build a hosting API that was a Python hosting API. And for making the dynamic operations run really fast, we had to build custom optimizations to make Python dynamic operations run really fast.

Resource Library:

In many ways, all the DLR does is it takes these things that we did custom for IronPython and it makes them work for a broad spectrum of languages. So instead of having a Python type system we now have a dynamic type system. So any language that has dynamic operations can share them… The point that we reached… its been fun watching this come together. It was a couple months ago in our internal work with the JavaScript team – theyre the ones whore releasing with us at the same time we are – theyre the furthest along. And we reached a point where we were doing a demo and somebody was complaining that event wiring hadnt been wired up yet for JavaScript. But their functions were working great.

So we were able to write a little program where we took a JavaScript function, passed it off to the Python code where event handling was working great and we wired it up as an event handler using the Python code. That to me was kind of the essence what we were trying to do.

By having this shared type system and these dynamic languages using the same sets of types, you can go back and forth between them. In the long run, things like wiring up event handlers, every language is going to have. But every language is always going to have the things that it does better. And the really cool code that somebody went out and wrote in just one language…if they could all talk to each other, you just get a lot of power as a language developer.  

In what ways?

Hugunin: The hosting API is in some ways obvious. Microsoft did this a long time ago with its IActiveScript APIs. And that worked really well. Theres an interesting thing about the IActiveScript APIs, the biggest technical issue, I find with the IActiveScript API was actually the security model. That in order to use those APIs…I can run Python in the browser today with the IActiveScript APIs. The only way I can do it, though, is if I have somebody ship me a version of Python that they guarantee is completely secure. With the DLR plus Silverlight I can now run Python in the browser again on top of the Silverlight engine. And the Python implementation that were shipping is completely security transparent. What that means is all the security is in the Silverlight engine; its in the .Net engine that were running on top of. And the language implementer just has to do all their code generation. And if we generate, and weve done it, but if we generate unverifiable code—essentially code that would lead to things like buffer overruns and horrible security exploits – and when our engine does that we get a nice error message that pops up in the browser saying you generated unverifiable code and tried to run it. And that makes it possible for a lot more languages to start running in this kind of environment, because you can build on the .Net security model.

The fast dispatch is sort of obvious. Everybody said these languages couldnt run fast on top of .Net, and IronPython was showing that they can run fast. But it was a lot of work. It took us a lot of work to get it to run fast. And what we want it to do is both to get it to run even faster and to make it easy for other languages to run in this environment.

John, what has your role been?

Lam: My role since getting here has been bootstrapping our Ruby effort. When I got here nothing had been done yet. Then we started off work in earnest against our Ruby implementation. And its really only been in the last month or so that things have really come together to the state where weve gotten this thing in the form that we could actually demo it outside.

And the cool thing is building Ruby on top of the DLR was so much quicker and cleaner and easier than having to go off and reinventing everything on our own – inventing our own object model, our own dispatch mechanism and the rest of those things. So the experience from Ruby really is to kind of validate the idea of the DLR.

Now, thats not to say that Ruby went into the DLR with no change to the DLR at all. But whats useful about the exercise of implementing Ruby and VB and JavaScript Python on top of the DLR is to validate the idea of the DLR, with fully understanding that expectation that the DLR will have to change at some level to accommodate these languages. But that goes to prove that its not just a pipe dream, but that there are going to be four solid implementations, and four fast implementations of these languages that all run on top of the same infrastructure.

Hugunin: Johns been really pushing on making sure that thats in fact true. Hes been building a wonderful demo for Mix. And its not those four languages; I want to make sure we dont forget that fifth language. The fifth language is C#.

Lam: I think whats really interesting about Silverlight is the fact that all this stuff, if youre building something in a dynamic language is just all text. And considering the way the Web was built using this kind of collaborative community knowledge of how to build stuff in HTML, JavaScript and CSS, much the same experience is going to happen in Silverlight, except were just going to replace some of the acronyms. Theres going to be some HTML still, but theres going to be XAML thrown into the mix, as well as the source code for a variety of different programming languages – be it JS, VB, Ruby or Python. But also the flexibility of, in certain circumstances, being able to throw some compiled C# code down there for performance reasons.

We have a demo of a chess application. And chess is great because its a very compute-intensive kind of thing that really makes static type systems shine in terms of showing the benefits of making code run really fast. So thats a great example of being able to use this chess engine, written in C#, and using it from the client inside of the UI that you can absolutely build out of one of the dynamic languages.

Next Page: Performance Review

>>> More Application Development Articles          >>> More By Darryl K. Taft