Microsoft's Jason Zander on Visual Studio and dynamic languages

SCOTT FULTON, BetaNews: Where do you see dynamic languages like IronRuby and IronPython being applied now? They've been proofs of concept in large part to this point, with the exception of Python knocking on the door of PHP. But IronPython is the solution to what?

JASON ZANDER, General Manager, Visual Studio Developer Division, Microsoft: I think you can pull up that question one more level, and ask, "What are dynamic languages a solution for?" I think you hinted at it, which is, "I want to rapidly produce something, prototype something, see how it works, and be able to throw that together in an easy environment." Usually that's the attributes you mention when somebody asks, "Why are you using a dynamic language?" It's easy to approach, it does less overall syntax, the concept count is lower.

The one thing I should point out is, we're not actually sitting still on static languages here, either. If you look at the introduction of LINQ and anonymous delegates inside of C#, those are examples where I had to type in less code, but it's still C#. So it's some of the best concepts that dynamic language developers love, only applied to static languages. I think there's actually rich, fertile ground between those two as well.

Then [to] your specific question, "What is IronPython then a solution for?" I think when people go into the mode of, "I want a dynamic language solution, smaller, faster," that sort of stuff, then it just comes down to, which dialect are you used to, and if you look at the domain, are there libraries and support systems that are there?

I'll give you an example: Python is actually heavily used in the scientific research community. You can find DNA sequencing algorithms that are in Python. It's also used quite frequently for scripting sites as well, so having the opportunity to have a .NET version of that means, if you want to program in Python or Ruby then you like .NET and you like WPF for Silverlight, then you can kind of combine both inside of Visual Studio. That's the kind of cool part.

SCOTT FULTON: Now, you mentioned prototyping as one of the key objectives. Is there something that can help individuals who have prototyped code using dynamic languages, to say, "Okay, now I see what this is like, I need to turn around on a dime and implement this in a conventional static language like C#?"

JASON ZANDER: I think the biggest thing that's going to help you there -- especially if you're using IronRuby or IronPython -- is, you are just using the .NET Framework in the first place. You can use intrinsic libraries in those languages, but you're also programming and importing .NET namespaces. That means that the code [modules] that you put together is going to translate just fine into Visual Basic .NET, C#, take your pick. And for that matter, if it's a smaller amount of "glue" code or something like that, you can actually weave it and continue to run that way, if you want. We just happen to write most of our big-scale production systems with C# and Visual Basic.

SCOTT FULTON: Are there any type of automated tools that can help, since we are addressing some of the same elements in the .NET Framework?

JASON ZANDER: We don't have what you're describing directly, although certainly, those concepts do exist. Usually those are migration tools; they pick up the syntax, they parse it, and they translate from one abstract syntax tree (AST) to another, and they re-emit the code. We do have things like that, internal technology that does that. We haven't actually written or shipped anything for Visual Studio that does precisely what you're referring to...Usually what you do is, you take the source code and basically do a port.

SCOTT FULTON: When you went back to leading Visual Studio last September, you said you'd gotten some inspiration from Expression, in terms of wanting to implement more "friction-free" features in Visual Studio. What are some examples of the techniques that Expression inspired you to do when you took over VS?

JASON ZANDER: Well, for example, there are several things that I actually like about Expression. One of those is the ability to search and find things a little more easily. For example, if I look at Visual Studio, I have a tremendous amount of richness in there inside of the Control Toolkit; there's tons and tons of controls. How you go through and find things and organize them quickly, things like that.

I think the other thing that's really great about Expression is, it implemented a split view system from the get-go. So while I'm in Blend, for example, I can click on the XAML tab and see XML, or I can click on the Designer tab and I can see the interactive workspace. That's actually a very nice feature, and we do have that feature in Visual Studio 2008, both for the Web site where I can actually show a split view of HTML, [and] we have the same thing for XAML with WPF as well.

I think in reality, you're going to wind up seeing both of these tools [Visual Studio and Expression Studio] get used. Now, what we've described is this designer/developer workflow. I like to tell people, "Look, I'm not a graphics person. I draw stick figures. I'm really bad at this, you know what I'm sayin'?" I want a professional who knows how to make stuff look nice and pretty and appealing to a user. That designer, I believe, will always use Expression. And it uses the Project system that we have in Visual Studio, the same files -- the solution file, the XAML file, source code control, Expression has the ability to open those, edit those, and the designer can do that work.

Because of code separation, the markup for what that looks like in the code are two separate files. So now, as a developer, I can go into TFS [Team Foundation Server] and sync that source control system, I pick up all the cool-looking stuff that they gave me, I now go open up my .CS file, and I can actually start writing code that get into the elements that designed -- this button or this list or that panel. Then I put business logic and code behind it, I can check it back in, and now the nice part about it for me having the split view is that, if I do make any code that is going to manipulate the look and feel of things like that, it allows me as a developer [to] actually see it as well. I may not be trained in [Expression] Blend, but I can actually see it in my development environment and I can make minor tweaks, that sort of thing.

So I think that shops that have both the designer and the developer [like me], I'll use Visual Studio, the designer will use Blend, but it's nice that in Visual Studio I can actually have both in there available to me. And the important thing is, those things round-trip between the two of us, so there's not this great big cliff between the two roles.

Coming soon: More with Zander on how LINQ could change everything