Sponsored Link •
Anders Hejlsberg, the lead C# architect, talks with Bruce Eckel and Bill Venners about the process used by the team that designed C#, and the relative merits of usability studies and good taste in language design.
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.
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.
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.
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.
Deep Inside C#: An Interview with Microsoft Chief Architect Anders Hejlsberg:
A Comparative Overview of C#:
Microsoft Visual C#:
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:
And an entire portion of Ken Arnold's interview was devoted to design taste - Taste and Aesthetics: