A Conversation with Anders Hejlsberg, Part I

---

Anders Hejlsberg, a distinguished engineer at Microsoft, led the team that designed the C# (pronounced C Sharp) programming language. Hejlsberg first vaulted onto the software world stage in the early eighties by creating a Pascal compiler for MS-DOS and CP/M. A very young company called Borland soon hired Hejlsberg and bought his compiler, which was thereafter marketed as Turbo Pascal. At Borland, Hejlsberg continued to develop Turbo Pascal and eventually led the team that designed Turbo Pascal's replacement: Delphi. In 1996, after 13 years with Borland, Hejlsberg joined Microsoft, where he initially worked as an architect of Visual J++ and the Windows Foundation Classes (WFC). Subsequently, Hejlsberg was chief designer of C# and a key participant in the creation of the .NET framework. Currently, Anders Hejlsberg leads the continued development of the C# programming language.

On July 30, 2003, Bruce Eckel, author of Thinking in C++ and Thinking in Java, and Bill Venners, editor-in-chief of Artima.com, met with Anders Hejlsberg in his office at Microsoft in Redmond, Washington. In this interview, which will be published in multiple installments on Artima.com and on an audio CD-ROM to be released this fall by Bruce Eckel, Anders Hejlsberg discusses many design choices of the C# language and the .NET framework. In this initial installment, Hejlsberg discusses the process used by the team that designed C#, and the relative merits of usability studies and good taste in language design.

Designing with a Living Agenda

Bruce Eckel: I've heard C# was created in a room with a group of designers.

Anders Hejlsberg: Yes. It was the same room for four years. We're still in that room every Monday, Wednesday, and Friday.

Bruce Eckel: I'm curious about the design process for C#. I've been involved in several different language designs, either directly or peripherally. In the Python process, for example, Guido van Rossum is humorously referred to as the benevolent dictator.

Anders Hejlsberg: That's sort of my same position.

Bruce Eckel: You are the benevolent dictator for C#?

Anders Hejlsberg: I'm the tie breaker. Once we've gone around an issue enough, and it is time to just make a decision one way or the other, I make it. But in most cases the decision is obvious.

Bruce Eckel: Is that similar to how Turbo Pascal and Delphi were designed?

Anders Hejlsberg: Those were less formal. I designed Turbo Pascal mostly by myself. I designed Delphi with Chuck Jazdzewski and Gary Whizin, but the group was small enough that we didn't really need a formal process. For C#, on the other hand, it has worked really well to formalize: every Monday, Wednesday, and Friday from 1:00 to 3:00, we have a regularly scheduled meeting. We have a living agenda. Issues bubble to the top, and we knock them off. We have a wiki now on the internal web with the issues list, resolutions for them, and so on.

Bruce Eckel: How do issues bubble to the top?

Anders Hejlsberg: Well, they just sort of do. We have many ways customers can give input—software design reviews, news groups—all sorts of ways we get feedback on the language. The feedback brings up issues, bugs, inconsistencies, irregularities. So there are things we know we want to do. They end up on the list, and then we keep iterating. We'll look at one and ask, "Do we have any new thoughts on this? No new thoughts? Well, this thing has really rotted here for several weeks, let's try to attack it for thirty minutes and see if we can get somewhere this time."

Bruce Eckel: So when something smells bad enough...

Anders Hejlsberg: Or when something smells good enough that you want to do something with it in the next release, you work on it. But I think this process is just a way to make sure nothing falls through the cracks. You put everything on that list. Something can sit on that list for a long time, and then maybe you decide you're not going to do it. But at least it gets captured, and there's a way to revisit it. It will either happen or not happen, but it won't get lost.

Bill Venners: Who was on the C# design team and what roles did they play?

Anders Hejlsberg: The original C# design team was Scott Wiltamuth, Peter Golde, Peter Sollich, Eric Gunnerson, and myself. The C# 2.0 design team is Peter Hallam, Shon Katzenberger, Todd Proebsting, and myself. Most of the credit for generics goes to Don Syme and Andrew Kennedy from Microsoft Research.

Usability Studies versus Aesthetics

Bill Venners: How much of the design of C# was based on usability research, how much on marketing choices, and how much on aesthetics?

Anders Hejlsberg: Ultimately, good language design boils down to assembling a team of people who have good taste. It boils down to programming aesthetics, as you are saying. Good taste is extremely subjective and hard to define, but you can sort of recognize it when you see it. And I don't think any number of usability studies can give you what taste gives you, because usability studies tend to be very vertical. A study might ask, "What do you think of this particular feature?" But it's not easy to ask, "What do you think of this language?" Where would you begin? How can you possibly attack that in a two hour usability study? It's just impossible.

Bruce Eckel: Somebody has to have depth of understanding.

Anders Hejlsberg: Working with a programming language is a much more immersive process. People don't really come to appreciate a programming language until they've worked with it for months. And then they may gradually realize, "Wow, this is really comfortable." You just can't do that very quickly.

That being said, we did a bunch of usability studies, but they were more vertically targeted on particular features.

Bill Venners: For example?

Anders Hejlsberg: Most of it was actually usability studies of IDE features. We might ask, "Can people understand that they right click to do this or that?" We did some usability studies for the pure language syntax itself—I think we did some with properties and events, for example—but it was not necessary really.

I don't think that you get as high a yield from usability studies for language features as for IDE features. IDEs are very interactive. You can watch users right click menu items and get good feedback. For programming languages, the question is more, "Is it conceptually understandable?" That's done very well by having a customer advisory councils, sounding boards. You want places where you can say, "Here's what we're thinking about doing for this particular new feature. What do you all think?" And you actually urge them to shoot as many holes in it as possible, because you'd much rather know before you put in the feature than after. So unless a language feature is a complete slam dunk, we tend to make use of those kinds of sounding boards.

Next Week

Come back Monday, August 11 for part VI of a conversation with Elliotte Rusty Harold about the design of the XOM API. I am now staggering the publication of several interviews at once, to give the reader variety. The next installment of this interview with Anders Hejlsberg will appear on Monday, August 18. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Resources

Deep Inside C#: An Interview with Microsoft Chief Architect Anders Hejlsberg:
http://windows.oreilly.com/news/hejlsberg_0800.html

A Comparative Overview of C#:
http://genamics.com/developer/csharp_comparative.htm

Microsoft Visual C#:
http://msdn.microsoft.com/vcsharp/

Anders Hejlsberg was not the first Artima interviewee to mention taste. Jim Waldo made almost an identical comment about building a team of tasteful programmers in his interview:
http://www.artima.com/intv/waldo10.html

And an entire portion of Ken Arnold's interview was devoted to design taste - Taste and Aesthetics:
http://www.artima.com/intv/taste.html

Talk back!

Have an opinion? Readers have already posted 4 comments about this article. Why not add yours?

About the authors

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.