Microsoft's .NET Evangelist Spells Out Future Role for Dynamic Languages

In a very real sense, Microsoft may have had more to do with the creation of the so-called "dynamic language" than most any other company. Back when the BASIC language interpreter shipped as part of the ROM of machines like Radio Shack's breakthrough TRS-80, I and many other novice developers first experimented with the prospects of code that changes itself to suit the specific needs of users. It involved statements with terms like "POKE," which was exactly as dangerous as it sounds.

Today, the re-emergence of dynamic applications through Web-oriented languages like Python and Ruby has awakened an old spirit within Microsoft, which is rediscovering a concept it helped create decades ago...and after years of denying its presence and usefulness, has now come around to embracing it.

With the introduction of version 3.5 of that amalgam of technologies collectively referred to as the .NET Framework, Microsoft added a layer called the dynamic language runtime (DLR), which is designed to be more adaptive than C# or statically-typed Visual Basic.

During demonstrations at TechEd last week, simple game experiments that required a modicum of skill and patience for a C# Express developer - even an experienced one - were pretty much replicated by another demonstrator using IronPython, and a console whose command line looked wasn't so far removed from the "READY>" prompt of three decades earlier.

We got a chance last week at TechEd to spend a few minutes with one of .NET's and the DLR's leading "evangelists," Microsoft senior technology specialist Thom Robbins. First we asked him to help us distinguish between the DLR and the ordinary common language runtime (CLR). From there, he took the ball and ran with it, at one point even anticipating our next question and asking it for himself. What we learned was, Microsoft clearly wants to open the floodgates for DLR, but its intention (and perhaps its hope) is that a backup set of floodgates will help the momentum for DLR stop where the borderline for SOA begins:

Thom Robbins, Director, .NET Platform Product Management, Microsoft: Within the .NET Framework 3.5, we're introducing a set of APIs which have been coined the DLR, the "Dynamic Language Runtime." Really, what they do is give you the capability of injecting code during the runtime, which things like IronRuby, IronPython are really designed for.

From a developer's perspective, the Framework has always been about choice. I think everyone's known that since the beginning; we support 29 languages today, everything from VB and C# to RPG, the list goes on and on. What we heard from our community was that the DLR was something they wanted us to support.

Do we think that it will replace things like C# and VB? No, I think that there's reasons for both. I've been working with a lot of our hobbyist market, people that are interested in writing games and that kind of thing, where DLR has a lot of value. We're looking at some of the ASP scenarios, where people may want to go ahead and interject IronRuby or IronPython code.

Scott Guthrie showed this fantastic demo at MIX '07 of an ASP page, where he was typing in IronPython and IronRuby right into the page, and getting it to run. So we are seeing a lot of interest in it. We haven't actually committed to the final dates, but we're going to be releasing things like IronRuby. We hired John Lam, who works on the CLR team. He was...one of the main forces behind Ruby. He has a great background, and has had pretty substantial impact. I think from the developer's perspective, there's a buzz because it's giving them additional choices around languages, which is really what the Framework is all about.

The other part is, we're also introducing this as an open-source idea. So we're going to release an implementation of IronRuby and open it up to the community, which makes it a lot easier for the community to go ahead and add in new features, to modify the language, and to add additional things.

Scott Fulton, BetaNews: In the application model as provided by the Web, there seems to be a new dimension to what we've called "scripting." Dynamic languages seem to be suited for a new concept of applications that change themselves, that mold themselves to whatever the user is doing with the service at that time. And I'm wondering, how this new concept of service-oriented application is going to evolve under .NET? It seems that a service is something that's waiting to be consumed. It has a method that's wrapped around it, it has its defined inputs and [expected outputs]. Whereas a dynamic application turns the concept inside out; it says, "What do I do?" And I'm wondering how the pieces fit together.

Thom Robbins: If you look at 3.5 and our announcement around Silverlight, dynamic languages are a fantastic fit for the front end. This is really the idea of, as the world starts to look at SOA and SOA becomes real in things like BizTalk Services and WCF, we see there's kind of two ways that people are going to go: Services, being that middle-tier technology, are going to be written using WCF, [will be] hosted, and made available by things like BizTalk. In BizTalk services, we're providing some of that optimization model in the cloud.

Then there's front end. The front end wants to reuse and consume services. So the front-end aspects are things like, for us, ASP.NET, Windows Forms, WPF, dynamic languages within ASP, which really gives application builders the capability on that front end. We're not seeing a lot of interest so far on that middle tier for things like DLR, just because services on that middle tier do require a lot more information. People aren't necessarily going to change their purchasing scenarios in mid-stride. They're going to want a set of functionality that they're going to want to optimize around, and a set of operations that they're going to want to optimize around. So we do provide within WCF a declarative programming model, which makes it a little bit easier for things to change. So [when customers ask about] that middle-tier technology, they say, "Well, we want to run over HTTP today, but we want to run over TCP tomorrow." WCF gives you that capability of switching within the configuration file through declarations.

We really are seeing a lot of interest on the DLR side on the front end, when it's coupled with rich Internet applications. So the idea that you can take things offline. RIAs are becoming very popular within that. Silverlight, WPF, and things like Windows Forms and Acropolis cover those other areas, I think that's where you're going to see the majority of the DLR [interest] start to build around.