Anders Hejlsberg on C# and .NET

The TechEd 2001 keynote was presented by programming pioneer Anders Hejlsberg. As well as being the chief designer of Microsoft’s C#, his résumé boasts the creation of both Borland Turbo Pascal and Delphi. In this exclusive interview with Matt Nicholson, he gives an insight into his work since joining Microsoft, discussing C# and .NET.

Originally posted on DNJ Online, July 2001

Matt: What have you been doing at Microsoft, and what was your history prior to working for the company?

Anders: I’m actually a Danish citizen, born and raised in Copenhagen. I moved to the US about 13 or 14 years ago. I’ve been in the industry since 1979.  I started at the technical university of Denmark and in parallel with my studies founded a little computer company with some other folks. I think we were the first computer shop in Copenhagen, back in the nascent days before PCs.  We were distributors of a British kit computer called Nascom. It was Z80-based and I wrote a whole bunch of different software such as assemblers and disassemblers – you know the kind of stuff you would write back then. I also wrote a small Pascal compiler. You could yank out your Microsoft ROM Basic and slot in our little Pascal compiler. It was in a sense the very early predecessor of Turbo Pascal. It had an on-screen editor, it would compile in memory and then execute machine code. It grew into a more full-blown implementation on CP/M, and then my company hooked up with the founders of Borland and licensed this technology to them. That basically became Turbo Pascal. They re-branded the software that we had written.

Matt: What was your company called?

Anders: It was called PolyData. Eventually that grew into a much bigger business than anyone could have ever imagined and I ended up doing nothing but software development for Borland. Eventually I traded our royalty contract for an interest in Borland itself and also relocated to the US. I was with Borland for 13 years, since it started in 1983 until 1996. We shipped probably seven or eight versions of Turbo Pascal and three versions of Delphi, which was the successor of Turbo Pascal. I was the chief architect of that product.  Then I moved to Microsoft in 1996. I needed to try something different after 13 years!

Matt: Was that to work on .NET?

Anders: It was actually before .NET. We did not start on .NET until late 1997 or early 1998. When I first came to Microsoft I worked as the architect of Visual J++ 6.0. Microsoft had shipped version 1.1, which essentially involved slotting a Java compiler into the Visual Studio IDE. There was really nothing other than the compiler that was Java specific; the project model was still the C++ project model and it wasn’t quite right.  So we built what became Visual J++ 6.0 and also the Windows Foundation Classes, our Windows specific class library.

Matt: How involved were you with the WFC?

Anders: I was the architect of WFC.

Matt: Some people regard the WFC as a forerunner of a lot of the ideas in .NET.

Anders: It was certainly the forerunner for what is now called WinForms (or Windows Forms) in the .NET Framework. So our client UI package in the .NET framework has a direct heritage from WFC. Anyone who knows WFC will immediately feel familiar with WinForms.

Matt: So will the Jump to .NET toolkit also be familiar to J++ developers?

Anders: Absolutely, and it is clearly targeted at two groups: people that develop with Java using the Sun class libraries, and people that develop with J++ and the WFC classes. The step from WFC to Windows Forms is almost a mechanical one. We use different conventions, and we now have a language that properly supports properties and events, and therefore certain things have a different syntax. It’s evolved to the next logical step, but it is a direct descendant of WFC so there’s nothing really structural that would have to change about the code. Any code you’ve written with the Sun class libraries, of course, involves a very different development philosophy and so the translation step is somewhat more involved.

Matt: What were the other inspirations or building blocks of .NET?

Anders: I would say a lot of the VB code that we had and, of course, Java itself served as an inspiration. A lot of customers were using Java and telling us they liked to use it. We have a lot of respect for that platform, no doubt about it.

Many other things served as inspiration, given my background. Delphi certainly has always served as an inspiration – you can also see that in the Windows Foundation Classes. It’s hard to unlearn things that you feel are right. I think it’s common with software development. Java was definitely influenced heavily by Smalltalk and other such object oriented systems.

Matt: What is your involvement with C#, and when did you start work on it?

Anders: I am the chief designer of the C# language and we started work a little more than 2 years ago – so late 1998.  We had started work on what is now the Common Language Runtime in the .NET Framework sooner than that, so we developed the language and the compiler in parallel with the runtime.

Matt: What was the reasoning behind C#? Why did you feel a need to develop a new language?

Anders: I think there are many reasons. First and foremost, we wanted a product that we could address at our C++ developers that would bring them to that next level of productivity and ease of use. You could argue that what we were really shooting for was the power and expressiveness of C++, but with the ease of use of languages like Visual Basic and Delphi.

Then I guess there were also some other big ideas. One of the key observations was that there had been an evolution in programming languages from what I would call structured programming, such as C and Pascal, into procedurally oriented languages which had proper ways of building data abstractions through structures and records, and so forth. That grew into object oriented programming starting with languages like Simula and gradually got adopted into the mainstream with C++ and object Pascal.  What we’ve tried to do, going from C++ to C#, is firstly the simplification I talked about earlier, and increased productivity, but also to build a language that supports what I call component oriented programming.

Over time, a whole model of programming has evolved that we call the PME model – the properties, methods, events model of building components. You could also roll into that things like integrated documentation and attributes that define how components slot into hosting environments. You want a language in which building components is completely natural, and all aspects of building components are first class in the programming language.

If you look at say C, C++ and Java, or languages that are sort of OOP but not necessarily component oriented, you’ll see that things like properties, methods and events are actually almost universally employed as a paradigm. ActiveX controls, JavaBeans, Delphi, or whatever – everybody uses that sort of paradigm for building components.

But these programming languages don’t really have all of these core concepts as first class language elements. For example in Java, sure you have methods, but properties and events do’?t really exist; they’re emulated through naming patterns. We all sort of agree that a property is two methods, one called ‘Set xxx’ and another called ‘Get xxx’. Indeed, when you look in a property inspector it actually shows up as ‘xxx’ and you have to know that you have to put the Set and the Get in the right places.

It’s the same for events. Yes there is the high level concept of events, but they don’t actually look like events in your language. They look like interfaces and adaptor classes that forward the calls and implement the interface, or anonymous inner classes, or what have you in Java. You?ve all seen the stuff that tools like JBuilder, or whatever, will spit out for all your event wiring, right?  We felt that the time was right to add those as first class language constructs, in the underlying platform as well as in the programming language.

As an analogy, with C you can certainly do object oriented programming; it’s just harder. You can lay out your own v-tables and pretend to have methods and virtual dispatches, and so forth, but it’s complicated.  And it’s the same with C++. You can do component oriented programming, it’s just harder. You have to do all sorts of macros, and IDL files, and type libraries, and what have you. We wanted to roll all of that in and give you that ‘one-stop’ experience of programming.

Matt: How have you achieved that with C#?

Anders: With C#, we’ve actually formalised it into language constructs. We have these things called ‘delegates’ which are object oriented function points. They serve as the core data type that encapsulates the notion of delegating control from an event source to the events thing. We also have the notion of declaring event members in a class.

Matt: Quite a few people talk about C# as being the native language of .NET.  Would you agree with that?

Anders: Well no, I don’t think there is a native language of .NET. The .NET Framework itself defines a complete abstraction of a programming environment, complete with a type system, an instruction language, an execution model, a security system, versioning and so on.  It was specifically designed to be multilingual. It was designed not to have one native language. We wanted to be able to host this new language called C#, but certainly also Visual Basic.NET, the managed extensions for C++, JScript and, at the latest count, some 15 or 17 languages that have been built by partners in the industry or in academia.

It is true, however, that the birth of the Common Language Runtime coincided with the birth of C#, and in a sense with the design of C# we had the luxury of not having any backwards compatibility to worry about.  But that doesn’t mean that it’s more native. It just means that we didn’t have any ‘compatibility tax’. But in terms of what we actually support, certainly anything you can do in C# you can do in managed C++ as well, and almost anything you can do in C# you can do in VB.

It used to be that there was a vast gap between Visual Basic and C++; literally two completely different worlds. Not only were the languages different but the entire class library was different. Practically none of your skills transferred. With the Common Language Runtime it is 99 per cent the same; it’s the same execution system, the same class libraries, the same model of development. It all runs in ASP.NET, so if you’re building web pages it’s the same HTML around you. It’s just the syntax and, even then, I would say 99 per cent of the features of the runtime are supported by both of the languages.

It’s only once you get into the corners of the corners that you start to see differences. C#, for example, supports unsafe code which Visual Basic doesn’t. If you really have to delve down and manipulate pointers and interoperate with this very complicated old style API then C# might be a little easier. On the other hand Visual Basic supports dynamic invocation in a late bound fashion, where you can invoke without knowing at compile time whether the method exists. That’s substantially more complicated to do in C# because you actually have to use the reflection engine. You call ‘object dot invoke member’, and pass in the method name as a string and an array of objects that represent the arguments, and so forth.

So once you get out into those corners you could say that C# is skewed a little bit more towards the power programmer and VB a little bit more towards ease of use. But in the grand scheme of things it is an almost insignificant difference when you consider the enormous steps we’ve taken in terms of unifying the platform and unifying the underlying class libraries.

Matt: Some of Microsoft’s partners seem to be having problems implementing languages such as  Python under .NET.  Does this stem from the fact that the basic object model of .NET is not the same as the object model of Python?  In which case, although .NET is language independent, it does arguably impose certain object models which are part of the language?

Anders: I think you have hit the nail on a very real problem. It would not be sincere for me to say that it is completely frictionless to take any random language and implement it on .NET. Obviously there is some work involved in doing so. We have worked with partners in industry and academia, though, who are implementing these languages, and listened to their problems. We have actually changed the runtime as a result of it. It has cost us real time on the schedule to make these changes in the behaviour of the runtime.

The runtime is a representation of a grand union of features between all of these different languages that are hosted. That’s why we’ve developed it in parallel. Is it perfect?  Nothing is perfect, but I think we’ve made a lot of progress, and indeed these languages are being implemented and are functional. Yes, the models are different. A lot of these languages are actually self-contained little environments where there’s never been the notion of an external world.  So you can implement them, but the real power comes from adding a few extensions that allow you to call these APIs. Then this whole additional world opens up without you having to throw away all of your existing skills. People have tremendous investment in skills, and the software they’ve already built, and if we can help them leverage them we are doing them a service.

Matt: Another area of concern is the integration between .NET and the COM+ services. Transaction handling and message queuing, for instance, are not native .NET services?

Anders: Well some of them are and some of them aren’t. You are right that transactions are still handled by the COM+ code. But think about what people do with a transaction coordinator: they co-ordinate transactions between managed and unmanaged code. It would be silly of us to presume that now that we’ve shipped the .NET Framework everything is managed and, if you have a transaction that you need to coordinate with some existing COM stuff, well you’re out of luck. That would not fly. We know that we have to evolve very carefully in that particular area. We fully support MTS, but you’re right that you will have to register your managed classes as COM objects when you use them.

Matt: So they will use the COM Interop?

Anders: Yes exactly, but because we have great COM Interop you can actually do this and it works. The same is true for MSMQ; we have managed encapsulation that makes it vastly simpler to deal with MSMQ, but you can use it from both managed and unmanaged code. Part of the power is that it is shared; it is accessible from both your existing code and from your new managed code.

Matt: But if you’re lucky enough to have a completely green field development, where you’re designing a stand-alone application on the .NET platform, and you want to use the scalability and features that MTS gives you, you still have to go through COM Interop?

Anders: That is correct. Although you don’t see it, it’s more of an implementation detail. You have to register things in the registry and deal with some other things. But it’s not like you have to do a whole bunch of gory, ugly programming in order to make it work; it’s quite seamless. It’s true: some things, like side-by-side execution and some of the versioning stuff that the runtime brings you, don’t come as quickly with COM+.  We’re fully aware of the situation here too, and we’re definitely looking at entirely managed solutions. But I think interoperability will continue to be a high order bid here. Certainly it’s the most practical way for us to make sure that you get full inter-operability.

Matt: But we can look forward to a time when transaction management and message queuing are native .NET services?

Anders: Yes, you can apply that metric to anything that we do. We are deeply committed to this platform and literally any piece of functionality that you see on Windows we are looking at ways of making it easier to access more efficiently in a managed world. It’s not just MTS and transactions, it’s everything that we’re looking at. But of course it’s a massive undertaking.

Matt: Finally, can you tell us what you’ll be talking about in your keynote at TechEd in Barcelona?

Anders: I have not nailed down precisely what?s going to be in that keynote.  It’ll obviously be in my area of expertise, which means it’ll have to do with the .NET Framework, the Common Language Runtime, the C# programming language, construction and consumption of Web Services, and perhaps a look at some features in Visual Studio.

Matt: Are you giving the keynote at the US TechEd in Atlanta?

Anders: No, I’m just doing the European one.

Matt: So it is exclusive to Europe?

Anders: Yes it is.

Matt: And given by a European.

Anders: But I promise not to give it in Danish!