Microsoft accommodates dynamic languages
- 24 August, 2006 07:22
The growing popularity of dynamic languages, such as Perl, Python, and Ruby -- which are popular for building Web applications -- has caused companies such as Microsoft, IBM, Oracle, and Sun Microsystems to stand up and take a look. Although Microsoft has championed development using traditional Windows development languages such as Visual Basic and C#, the company has recently made accommodations for dynamic languages, with projects such as IronPython and Phalanger hosted on Microsoft's CodePlex site for community development. Still, Microsoft is largely leaving it to the community at large to provide the dynamic-language capabilities on the .Net Framework. Jason McConnell, the Visual Studio product manager responsible for all languages at Microsoft, talks about the state of dynamic languages on .Net.
Jason McConnell: We always want to enable as many languages as possible for the .Net Framework, especially the ones that our customers are demanding. Dynamic languages like those you mentioned have gained popularity of late, and so officially, there's no official stance except to say that we're looking into how we can enable languages like that to be a great programming experience on the .Net Framework.
So when you say you're looking into it, what steps do you think Microsoft might take? Obviously you're getting some feedback from customers and developers that they want this sort of functionality?
JM: Right. We're looking at those new languages that people are using now. For example, we have a project called the IronPython project that recently went to Release Candidate status. It's kind of like a community project, but it shows early efforts to enable a dynamic language on the .Net Framework. So we've used that as kind of our poster child, if you like, for our strategy or our work into that space.
Do you believe the traditional Microsoft-friendly languages such as Visual Basic or C# offer advantages over these dynamic languages?
JM: Well, they're kind of different beasts. C# is a strongly [typed] static language if you like. VB could be considered a dynamic language; it's always had dynamic aspects to it. [Dynamic languages are] most suited for quick, rapid application development, whereas the statically [typed] languages are for building larger systems with well-defined interfaces. So it really depends on using the right tool for the right job. I think it's unfair to compare a statically [typed] language to a dynamic language.
I'm looking at a definition of dynamic programming languages on Wikipedia here. What would be your definition?
JM: A dynamic language is one that can resolve types and kind of compiles on the fly; in that way it's very dynamic. So, at runtime, the compiler does type-checking and syntax-checking as opposed to a static language, which is done at compile time, which is not at runtime.
To what do you attribute the popularity of these new languages? Their advantages in Web development, perhaps?
JM: Definitely the Web has made an explosion of these things possible. I think Web services as well, not just Web sites and scripting engines like JScript and the engines that are embodied inside of browsers, but also the ability now to stitch together components on the Web, like Web services. If you look back in the mid- to late-90s, scripting was really popular as a macro language behind Office. And we were sewing together, from the COM (Component Object Model) days, we were sewing together components that were just Windows-based and stitching them in together to make applications for Office and end users. And we see the same trend happening now for the Web. So I think it's about sewing together almost like Web mash-ups, you know? Sewing together services and making composite applications, which has really started to reignite this area.
How does Microsoft feel about some of the third-party efforts going on for dynamic language supports on .Net, such as Ruby in Steel or the Phalanger project for PHP?
JM: We're very supportive, as always, of encouraging a third-party ecosystem of languages. This has been true since 2001 when we first envisioned this CLR. So we're very supportive of that and in fact our Lang.Net symposium that was run a couple of weeks ago was kind of like a first try at trying to corral some of the ideas that are out there and foster the idea of a community to build languages around .Net.
What would you say was the major feedback from that event?
JM: Oh, it was overwhelmingly positive, from what I can tell. We actually had industry spokespeople, we also had people that do this for a hobby. [There was] lots of just sort of intellectual discussion. And it was a great forum for early thinking about emerging technologies. So I think it went over very well.
Was there any major concrete policy stance that Microsoft has made based on that event?
JM: No. It was really just to bring the industry together and have a chat, if you like. It was kind of elbow patch-wearing academics as well as some of the industry people. So it's kind of seeing where the trends are emerging. So obviously we'll take some of that back in-house and think about it, but we haven't actually made any stance as a result.
Are the days numbered for Microsoft traditional languages and the rival Java language, with the growing popularity of these dynamic languages?
JM: I think I'd term Java and C# and C++ as system programming languages, and there will always be a place for system programming languages because they're well suited for rigid, well-defined, industrial-strength programming stuff. Downstream from that, the good system programming languages will be used to bubble up and surface macro functionality. So [there will be a] larger logical box of units of work, if you like, and they'll be stitched together using scripting. And that's where these dynamic languages are really going to play strongly.
Is the CLR unfriendly to dynamic languages?
JM: We made improvements in the .Net Framework 2.0 to be able to do dynamic calls. We're looking at ways that we can make dynamic languages friendlier, but it's certainly not unfriendly to dynamic languages right now. If you look a Jim Hugunin's work in IronPython, you'll see that there's some really good things. In fact, that's why he came to join Microsoft.... He turned around IronPython in a pretty short time frame, so it shows you that it's not unfriendly.
With these projects Phalanger and IronPython, does Microsoft actively support those with developer resources?
JM: No, we don't. They're very much driven by the community.
(Editor's note: IronPython started as a community project but has since been brought into the Microsoft fold).
Is there a short list of specific dynamic languages that you guys are working to extend support for or to make easier to run on .Net?
JM: Not at this stage. We're kind of looking at how dynamic languages in general can run better. So it's really done in exactly the same way as CLR is common across languages. But that's same sort of work we're doing, or thinking of doing, for the runtime.
So whatever improvements or tweaks you make to the CLR for dynamic languages should extend to any dynamic language?
So you don't envision a Microsoft version of PHP or Perl or any of these? You're going to let pretty much the outside developers take care of that?
JM: We haven't made any firm plans in that direction right now.... The .Net Framework should really be seen as an industry leader in enabling these sorts of languages. We're constantly evolving it. It's at Net Framework 2.0 right now, 3.0 will be out with Vista. [Version] 3.5 or something like 3.5 will be out with the next set of tools that we release. So we're constantly improving, always looking for what's important in the industry and from our customers. And you'll always see us evolve this and do some innovative work.
Join the Computerworld Australia group on Linkedin. The group is open to IT Directors, IT Managers, Infrastructure Managers, Network Managers, Security Managers, Communications Managers.
Optus goes over the top with VoIP service
Turnbull asks how the NBN got that way
U.S. retailers insist on PIN requirement in smartcard rules
Yelp speeds database access with flash storage
Thanks a million, Drupal