Microsoft Distinguished Engineer Anders Hejlsberg is chief architect of the Visual C# language and has been a key developer of the company's .Net application development technology. Previously, Hejlsberg wrote TurboPascal when he was with Borland Software. He also was chief architect of Borland's Delphi technology. InfoWorld editor-at-large Paul Krill talked with Hejlsberg at the Microsoft TechEd 2005 conference in Orlando this week about a range of application development topics.
What was the intention with Visual C#? C++ and Visual Basic have been successful. What was the need for C#?
It was effectively to create a modern language in the curly brace family, if you will. The C family of languages, they're essentially known as the curly brace languages because when you write code in C, you use curly braces. So [we created] a language that was sort of rooted in the C family of programming languages, where we find C itself and C++ and Java, but tailored for the .Net platform. That's sort of in a nutshell. If you want to look a little bit more about what are the things that made C# special as a programming language, say compared to C++ or Java, we could talk about that, or about how .Net sets itself apart [from Java] or [other languages].
So how is it set apart from C++?
C++ is what we call an unmanaged language or a language that does not have all of the newer features that characterize languages like Java or C#, like garbage collection, type safety, exception handling or mandatory exception handling, code verification, [and] metadata. All of those things are sort of things that characterize .Net and Java at the run-time environment. And C# is sort of a language that was created to be a natural evolution of C++ onto the .Net platform. [The priority] first and foremost [was] programmer productivity. I mean all of what I've done for the 25 years I've been in this industry [has been] sort of a relentless quest for more programmer productivity and then C# is just sort of continuing that tradition, right?
What's the user base of C# as opposed to Visual Basic or C++?
It depends on how you count. If you count in Visual Basic, VB6 and VBA (Visual Basic for Applications) and VB.Net and whatever, it's obviously an enormous user base that dwarfs practically everything else. If you look at C# vs. VB.NET vs. C++, [managed] C++ on the .Net run time, I'd say C# and VB are about neck and neck. I believe they're about 45 and 45 percent and then managed C++ is the remaining 10 percent or something like that, I think. But that's just if you look at who runs their code on .Net. I don't even think I have numbers in my head about how many VB6 programmers there are in the world, but it's in the millions, and the same is true for C++.
What is your take on the Edit and Continue feature that was added to Visual C#?
Originally we had planned not to support Edit and Continue, because we weren't sure that we could find the time to do the work in the IDE. But sort of halfway through the development phase of Whidbey we realized that there was actually enough time on the schedule to do the work, so we added Edit and Continue as a feature, also based on a lot of user feedback. VB6 has Edit and Continue and in the first releases of VB.Net it was not supported. So in 1.0 and 1.1, the 2002 and 2003 releases did not have Edit and Continue and a lot of VB users were really missing it. But it's not really a VB feature as such, it is a program or productivity feature. And since a lot of the work to support Edit and Continue actually goes into the .Net platform, we're sort of positioned to take advantage of all of that if we just do a bit of work that we needed to do in the IDE itself.
Besides the Edit and Continue feature, what is the main benefit for Visual C# users in Visual Studio 2005?
If we look at the IDE itself, Edit and Continue is one of the big ones. The other big one, I would say there, is code refactoring. [It's] sort of the ability for the IDE to do a lot of the tedious edits to your code that you [would] end up doing as a programmer yourself. Let's say you have a method and you want to add an extra parameter to it. First [you would have] to find a method [of] adding an extra parameter, then find all the places where the method is called and add an extra default value onto every call there. But with the refactoring, the IDE can do all of that for you, and it can do it much better always, because these edits tend to be very mechanical that you do to your code. All of the refactorings, like change the name of a method, add an extra parameter, it's the same work you do over and over, and machines tend to be much better at the mechanical stuff and we're better at the creative stuff. So in effect we do more of the mechanical work in the IDE, leaving you more time to think about the code and the algorithms and the part of the equation that the human is good at. So that's sort of, from the IDE side, one of the other big ones. In the language, I think by far, the biggest feature is generics, which in a nutshell is the ability to parameterize your types. When you write code, clearly code is much more useful when you can have parameters on your methods and your functions. And the same is effectively true for types. Types can be much more useful if you can parameterize them. I don't know if you want me to go to the next level of detail and give you sort of a look into what generics does.
A couple of sentences, maybe.
Before generics you couldn't write, for example, a container class. Let's say I want to write "My Smart List," you know, that's going to be able to store objects using a binary tree or whatever, or it's got a model, a table and a database. But I don't actually know what the table is going to be a table of. But I do know that I want it to have an Add method and a Delete method that adds a row or deletes a row and so forth. With generics, I can actually write code for a table of some type and I can say, call that Type T. And then later I can give T, say table, a customer table and they will all share the code and the compiler. The type system will do all the type-checking for you. So you can parameterize your types effectively.
What is the importance of the C-Omega project at Microsoft?
C-Omega is a research project that explores language extensions in a couple domains. One is database integration, the other is XML. And C-Omega was effectively sort of conceived as, let's take C#, let's try and take SQL, let's try and take XML or XQuery and let's all sort of put them into one big bowl and stir and see what comes out of it, experimenting with integrated queries and so forth. And it's interesting in that it sort of shows an interesting amalgam of different programming languages and query languages and so forth. And we've learned a lot from that prototype, and we are now working to apply a lot of that knowledge in C# and our other programming languages. So one of the things that the C# team, specifically, we've been thinking about for the last almost two years now is really trying to make inroads on the deep impedance mismatch that we have, generally speaking, between programming languages and databases.
When I ask programmers, in fact I tried to ask them yesterday at my talk, how many of you access data in your applications or talk to a SQL database? And at first, everybody laughs, and then they all raise their hands and they go, what a stupid question. But really, what I take away from that is that when you are learning to program in C#, you're actually not just learning to program in C#, you're also learning to program in SQL and you're also learning the APIs that tie together C# and SQL to form your full application. And when you look at those two domains, it is remarkable how different they are. SQL is based on relational algebra, so everything in SQL is a table with rows and columns. .Net, then C#, VB, it's all objects and hierarchies and inheritance ... and virtual methods. It's completely a different concept. The data types are different. In SQL, everything is nullable, things can be null. In our mainstream programming languages, things cannot be null. And now you've got to deal with the nulls. In SQL you write queries, and so I have a higher-level declarative way of expressing the set of data that you're interested in. [With] general purpose programming languages, you've got to write four loops and if statements and so forth. Often programmers sort of end up just being plumbers that tie together the domains, and the big problems they worry about are how to make the null go away and how to write the queries and strings and get the traffic over to the server and get the results back and so forth. So what we're looking at is really trying to much more deeply integrate the capabilities of query languages and data into the C# programming language. And I don't specifically mean SQL, and I emphatically don't mean just take SQL and slap it into C# and have SQL in there. But rather try to understand what is it expressively that you can do in SQL and add those same capabilities to C#.
So there's not going to be a separate C-Omega product?
Is any of the C-Omega technology going to be in Visual Studio 2005?
It's beyond that, obviously?
Yes. All of what I'm talking about is beyond Whidbey. But the thing that's interesting about Whidbey is that in Whidbey we are laying the groundwork for a lot of this that I'm talking about now. For example, C# now supports generic types that I just talked about, and it turns out that in order to really do some of this deep integration that I'm talking about, you need types that can be parameterized because otherwise the type system isn't rich enough. Another thing that C# 2.0 adds is nullable types ... All of those things are sort of cornerstones for the next level of progress that we can make into this domain of better integrating data with programming languages.
What is your take on Java and where that's going? Do you believe that there'll always be Java and .Net or is one going to defeat the other? What accommodation is Microsoft making for Java, especially since you're supposed to have this relationship with Sun Microsystems now?
Right. It's hard for me to say what's going to happen longer term with these two. I certainly think that if you look at where we were five years ago with .Net and where we are now, I mean effectively .Net didn't really exist five years ago, and at this point I think anyone will say that we're at least neck and neck and maybe even we're starting to actually pass them in terms of adoption. So I think we've made tremendous inroads with .Net. I think we've had the right strategy for creating a multilanguage run time as opposed to a run time for our single programming language. I think that has really panned out and has been the right strategy for us and for our customers. I think going forward, it's interesting that Microsoft in many ways is positioned to, for example, better solve the problem that I've just talked about than say Sun is with Java. One of the things that's interesting about the problem I was talking about earlier is that it isn't specifically just a thing that you do in a programming language. How do you get better integration? Well, it involves your data stack, it involves your programming languages, it involves the run-time infrastructure, etc. It's very hard for Sun to address the whole issue because they don't have a database that they could better integrate with their programming language, for example. The opportunities that we can pursue, [for example], deep integration, are what I think will set our platform apart going forward.
What is your take on Eclipse and the Eclipse Foundation and Eclipse IDE? At this point Eclipse has Sun and Microsoft not participating and everybody else pretty much is. What does that mean?
Eclipse is an open source project built around the Java platform, so I don't think it's so surprising that we're not partaking there. I would say we're competing there, and I think we're competing quite well with Visual Studio. A lot of the features you see in Visual Studio 2005 bring us not just neck to neck, but ahead of Eclipse, and I think it's healthy to have competition. As always, it's going to keep us on our toes and it's going to keep them on their toes.
But you have to spend money for Visual Studio and you can download Eclipse for nothing.
That all depends on how you look at it. You can download the Visual Studio 2005 Express Editions for nothing, and I would argue that in many ways they are better, more deeply integrated tools than some of the stuff you can do with Eclipse. And conversely, with Eclipse you typically end up paying money anyway because you buy a particular distribution of it and you buy it as part of [IBM] WebSphere or whatever and you actually do pay money. So it's not that clear, it's a bit of a fallacy that everything is free in that space and everything costs money with our platform.
Have you worked with the Eclipse environment at all?
I've played with it, but I don't use it day to day because I don't code in that environment day to day.
What was your impression of it?
Oh, I think it's got lots of nice stuff. It's definitely a real product, I mean, no doubt about it.
What do you think the endgame is for Eclipse? Take over the industry?
It certainly seems to be taking over a lot of the Java IDE industry, but that's just me observing what's going on there.
In the past few months you have BEA, Borland, and now Macromedia using Eclipse as a basis for a lot of their technology. What do you think that means? That software companies are relying on the Eclipse IDE?
It's a good question. I think in many ways it makes it harder for these companies to control their own destiny when the IDE has been commoditized to the extent that you're now just writing plug-ins to an IDE as opposed to actually bringing a new IDE to the world. By the way, with Borland, not all of their tools are based on that. They also have a whole offering for .Net, the Delphi [technology].
Are there any open source plans for Visual Studio or anything other than what Microsoft's already done with the Shared Source initiative?
No. Not to my knowledge, no.
What is your take on Mono?
Oh, I think it's great, I think it's proof that standardization works, that the work that we've done in ECMA to standardize CLI [Common Language Infrastructure] and C# actually has [results] and we have seen completely independent third-party implementations of the infrastructure. So I think it's a good thing. I think it's more good for us than bad for us.
During a panel discussion last night, one of the speakers, from a college, said his school has anti-Microsoft people, but so does every college. What would you say to the anti-Microsoft crowd, either corporations or universities or whatever, about Microsoft?
I've been at Microsoft now for about eight years, and I've certainly seen a big shift in the attitude from the company toward its customers. There's much more transparency at Microsoft now, there's much more openness. You see, I don't even know how many hundreds or [maybe] thousands of bloggers that we have inside Microsoft talking about exactly what's going on. [There's] much more customer interaction. And I think the whole attitude and the whole approach with which we developed .Net and had deep involvement of third-party language implementers from the very beginning of the platform goes to show that really it is a different Microsoft. And it is a different approach to our customers and I think we've gotten much better at listening than we were when I started.
You would say that whole anti-Microsoft attitude started because Microsoft's customer relations were not as good as they should have been?
I mean you could say that's perhaps part of it, but quite honestly I think there is a mechanism in humanity that says once you get to be the biggest you get to get all the arrows in the back, and that's just how it is.
Are there any plans at Microsoft to port to any other chips besides Intel-compatible or any plan to support any OS besides Windows?
Not in my domain, no.