Whether he truly is an international superhero of C# as some claim, Anders Hejlsberg is certainly a visionary. Known as one of the ‘big brains’ at Microsoft, he was born in Copenhagen in Denmark and studied engineering at the Technical University of Denmark in Lyngby.

It was here that Anders began writing programs for the Nascom microcomputer including a Pascal compiler  for CP/M and MS-DOS and marketed  for the Nascom 2, under the name Blue Label Software Pascal, or BLS Pascal.  Later he went to work for Borland and rewrote his compiler to become Turbo Pascal for the IBM PC. This new compiler sold for $49.95, which was far cheaper than any other commercial high-level language. It became hugely popular in the 1980s thanks in part to an aggressive pricing strategy and having one of the first full-screen IDEs. It became popular with hobbyists as a structured replacement for BASIC. This was followed by ‘Super Pascal’ which had labels, a return statement and expressions as names of types.

Anders’ Turbo Pascal version 5.5 finally added added object orientation to Pascal, but the Object-oriented culture was in full swing, and  and so Anders and his team used  Apple’s draft standard for Object Pascal  to create Delphi with a reference-based object model, virtual constructors and destructors, and properties. Delphi is still used to this day to produce high-quality commercial software.

Anders joined Microsoft in 1996 and was architect for the Visual J++ development system and the Windows Foundation Classes (WFC). The WFC was primarily designed for creating GUIs for Java applications on Windows. J++ was close to Java, but differed in important aspects. A dispute with Sun over this was settled when  Microsoft agreed not to advance J++ beyond its mirrored implementation of Java, version 1.1.4. The technology of J++ was eventually recycled, and survived for a while, as part of the Microsoft .NET platform and the J# programming language.

Anders was rapidly promoted to Distinguished Engineer in 2000. He is now a Technical Fellow in the Developer Division and chief designer of the C# programming language and a key participant in the development of the Microsoft .NET framework.

Since its initial release in 2000, the C# programming language has been widely adopted and is now standardized by ECMA and ISO.

He has co-authored “The C# Programming Language”, published by Addison Wesley, and has received numerous software patents. In 2001, he was the recipient of the prestigious Dr. Dobbs Excellence in Programming Award.

RM:

“Anders, why is C# called C#. Wasn’t it originally named Cool? There’s a rumour going around that it was renamed because of the desire to attract geeks. I jest of course, but why the name change?”

AH:

“Yes, the codename for C# was COOL, which stood for C-style Object Oriented Language. We actually liked that name and even looked at keeping it for the final product, but the trademark lawyers weren’t, um, cool with it. So, we had to convene the language naming committee. We wanted to have a reference to the language’s C heritage in the name and finally settled on C#. Some other candidates I recall were e-C, Safe C, C-square, C-cube, C-prime, C-star, and Cesium… Looking and those now I’m pretty happy with our choice.”

RM:

“What were the fundamental flaws in other languages that you believe drove the development of Common Language Runtime (CLR), and in turn, C#?”

AH:

“I wouldn’t say we were motivated by fundamental flaws in other languages. It was more that we needed to modernize the Windows developer experience. At the time we had multiple distinct development toolsets, e.g. Visual Basic for Rapid Application Development, C++/MFC for systems-level programming, VBScript and IIS for Web applications, and so on. There was little or no sharing of code and skills between these toolsets and your application model would effectively dictate a particular programming language. Furthermore, application interoperability was done through COM, which is a very low-level mechanism, programmers often had to do explicit memory management, there was no common exception and error handling mechanisms, etc. etc. We wanted to fix all of those issues by creating a unified programming platform that supported multiple programming languages, was object-oriented at the core, and provided a shared API framework with modern services such as garbage collection and exception handling.”

RM:

“There’s no real concept of inner classes in C#–you can declare a class inside another class, but it’s not really the same as an inner class in Java, unless you’re talking about those declared static. Did you consider introducing them when you were designing the language? if so why did you reject them?”

AH:

“Correct, C#’s nested classes do not implicitly carry a reference to an instance of the enclosing class, so in Java terms they are like static inner classes. C#’s view is that nesting of classes is just a way to control lexical scoping. If you need to, it takes but a line or two of code to store a reference to an outer class instance in a nested class, so you can pretty easily emulate Java’s inner classes.

I think a much bigger difference is C#’s support of lambda expressions and closures, both cornerstones of functional programming. These are still missing from Java, although there have been multiple proposals to add them. In terms of expressiveness I think these are far more important than inner classes.”

RM:

“I’ve noticed that the event registration/un-registration thread is unsafe? Why is that?”

AH:

“No, that’s not the case. If you declare an event without explicitly implementing the add and remove accessors (the C# language specification uses the term “field-like event” for this), the C# compiler automatically generates thread-safe accessors for you.

Perhaps what you are referring to is that you must take extra care when writing thread safe code that raises events. For example, say you have a class that declares and raises an EngineFlameout event:

1 2 3 4 5 6 7 8

public class RetroRocket {   public event EventHandler EngineFlameout;     protected virtual void OnEngineFlameout(EventArgs e) {     if (EngineFlameout != null) EngineFlameout(this, e);    } }

This code looks innocent enough, but it isn’t thread safe. Specifically, a race condition arises when another thread unsubscribes to the EngineFlameout in the short period of time between the null check and the invocation of the event handler-the event might then become null and an exception would occur. The code can be made thread safe by first copying the event delegate into a local variable, i.e.

1 2 3 4

protected virtual void OnEngineFlameout(EventArgs e){   var handler = EngineFlameout;   if (handler != null) handler(this, e);  }

This is really no different from code that tests whether an object reference is null before calling a method on the object, it just so happens that we’re dealing with events here. As with literally any piece of code written in an imperative programming language, extra work is required to ensure thread safety.”

RM:

“It’s probably more of a CLR issue, but why doesn’t the “throw” statement work as advertised? It always resets the stack trace even if used without an argument ”

AH:

“If you “throw” without an argument (known as a rethrow), the StackTrace property of the exception is not reset. That is one of the main differences between the implicit and explicit forms of the “throw” statement. That said, the CPU stack is always unwound upon entry to a catch block, even if that catch block rethrows the exception or throws another exception. This might be the issue you are referring to. It is a natural effect of the CLR’s exception handling being built on top of Windows Structured Exception Handling (SEH). A team mate of mine, Mike Stall, has a good blog post on this topic:

http://blogs.msdn.com/jmstall/archive/2007/02/07/catch-rethrow.aspx ”

RM:

“When you want to hack up an experiment quickly, do you use C#? if not, what do you use?”

AH:

“Well, I pretty much do all my experimentation in C#. Dogfooding is important!”

RM:

“How do you think the introduction of the new “dynamic” type in C# 4.0 will affect application performance and reliability?”

AH:

“The “dynamic” type in C# 4.0 makes it much, much easier to interface with anything for which you do not have a static .NET type-for example, COM and OLE Automation libraries, the JavaScript and HTML object models, objects from dynamic languages such as Python and Ruby, or REST based Web Services. Where you would previously have to go through reflection-like APIs, such as Type.InvokeMember and ScriptObject.Invoke, you can now just write regular methods calls that are resolved dynamically at run-time.

C# 4.0 really is a happy marriage of static and dynamic programming-instead of picking one or the other, you get to do both in the same programming language.

I expect performance and reliability to both benefit. Similar to IronPython and IronRuby, C# 4.0 uses the Dynamic Language Runtime (DLR) for all dynamic dispatch, and the DLR has been extensively tuned to provide great performance.”

RM:

“By the time .NET came on the scene, Java had already been around for a number of years as a successful managed platform, and whilst there are obvious similarities between C# and Java, there are also some differences. When designing the C# programming language, what did you learn from the Java experience, and were there any shortcomings in that language that you tried to avoid?”

AH:

“Well, Java certainly demonstrated the value of type safety, exception handling, and garbage collection in a mainstream programming language. Those just do wonders for productivity.

Many programming languages influenced C#. Java was one of them, but C++ and Delphi also influenced our design. If I had to call out a few of the differences between C# and Java from a programming language point of view, I might mention C#’s unified type system (value types, boxing, and unboxing), first class support for properties and events, delegate types, separation of logical naming and physical packaging, and unsafe code.

Also, C# and .NET’s design for generics doesn’t rely on erasure but rather has true representation of type parameters at run-time. I think this brings about many important advantages. And, of course, in C# 3.0 we introduced Language Integrated Query (LINQ) which really has no counterpart in Java.”

RM:

“Do you believe the LINQ query comprehension syntax (is this its official name?) is a successful feature, or more of an interesting experiment?”

AH:

“We call them “Query Expressions” in the language reference, and, yes, I absolutely consider them a successful feature. The fact that you can write your queries in a high-level SQL-like syntax is incredibly important to a lot of programmers. It makes the feature much more approachable. Yet, because the compiler simply turns queries into sequences of method calls with lambda expression arguments, we get a great extensibility story.

When I talk to C# or VB.NET programmers now, most of them use LINQ in their day to day coding, be it LINQ to Objects, LINQ to XML, LINQ to SQL, the Entity Framework, or one of the many third party LINQ providers. And if they don’t, it is usually more a question of downlevel deployment than usefulness of the feature. The ability to query in-memory objects, XML, and relational data with a single unified syntax is just really compelling.”

RM:

“Nemerle showed that adding meta-programming support to C# was a serious possibility ? Have you ever considered it?”

AH:

“It is one of the directions we are looking at for future versions of C#. Indeed, I see meta-programming as a piece of our bigger “Compiler as a Service” theme that we are working on for a future release. We want to open up our compiler so it becomes an API you can call to compile a piece of code and get back expression trees and/or IL. This enables a whole host of scenarios, such as application programmability, an interactive prompt, user-written refactorings, and domain specific languages that have little islands of C# imbedded in them.”