C#: Yesterday, Today, and Tomorrow: An Interview with Anders Hejlsberg, Part 2by John Osborn
Anders Hejlsberg joined Microsoft in 1996, and did his initial work as an architect of Visual J++ and the Windows Foundation Classes (WFC). Hejlsberg is currently a Microsoft Distinguished Engineer and chief architect of the C# language, and he played a key role in the creation of the Microsoft .NET framework. Today, he leads the ongoing development of the C# programming language. John Osborn, executive editor with O'Reilly Media, Inc., responsible for the company's developer books on .NET and other Microsoft initiatives, recently sat down with Hejlsberg for this second part of a two-part wide-ranging interview.
Osborn: [When you introduced the C# language in 2000], your number one bullet was that this was the first language that was really component-oriented. Has [your] perspective changed in five years?
Hejlsberg: Well, it's become more than that, for sure. But [C#] is still what you could characterize as a component-oriented language. And that takes us back to properties, methods, events, and the core things that you deal with on a day-to-day basis in your programming. Back then, and even more so now, programming very much is aided by tools, and those tools very much tend to have a programming model where you have some sort of design surface where you put components, and then you modify the components, put code behind them, set their properties.
I always felt that [properties and events and methods are] such important concepts that they deserve first-class treatment in the language, and that's what we did with C#. And quite honestly, I have heard no complaints about the fact that we have properties. It is a complete non-issue, you know what I mean? It's just, "Yep, yep," people just think that's completely natural.
And in a sense, this idea of giving first-class treatment to things that we commonly do is something that is very dear to my heart. In many ways, it's the same [thing] we're doing with LINQ and language-integrated query, right? It's giving first-class treatment to the notion of a query in a programming language, because we all like queries. It's a declarative way of expressing something at a higher level than if you write a bunch of
for loops and
if statements and sort of do it the manual way.
Osborn: I want to come back to LINQ, but going back to the relative positioning of languages, again, one of the things that [Microsoft Visual Studio .NET product manager] Tony Goodhew said in that interview was that Microsoft studies were showing that people tended to use two or more languages to do their programming. And there was a sense at the time that [languages were just] syntactic sugar. You choose the language that you're most comfortable with.
Do you think that's changed? We don't say that anymore.
Hejlsberg: Well, we don't, but it's all syntax in the end, right? I mean otherwise, we'd just be handing over an XML document that describes the abstract syntax tree of what you want done, and that could be the syntax, too, but it's obviously not usable by programmers. So I think programming languages occupy a special position in people's minds in the sense that just as your spoken language is the way you express yourself, so is [your] programming language; it's how you express yourself.
And the syntax is the manifestation of the programming language, and it actually, in many ways affects how you think about your program and so forth. So syntax does matter, and it matters a lot, I think.
Why Syntax Matters
Osborn: What's special about C# in that regard? Can you characterize it?
Hejlsberg: Well, I think the component-oriented stuff that we talked about is tremendously important. We try to make sure that there are not multiple ways of doing things. We try to always find synergies between syntactic elements. It's hard to describe precisely what I mean by this. But take the language-integrated query [LINQ] stuff [we've introduced at the PDC, for example]. The extensibility model of that is that we turn it all into method calls. When you write a query with a
orderby, and a
select clause, we turn that into calls to methods called
Select on the collection you are querying. And we pass the expressions you wrote in the query as lambda expression arguments to those methods.
So queries just turn into method calls that are strung together, but the query syntax makes it easier to read, even though it is simply a syntactic veneer. It immediately translates into method calls, just like the
foreach loop translates into get a numerator on a
while loop and so forth. But it helps you think about it at a higher level. Do you know what I'm saying?
Hejlsberg: So in that sense, syntax deeply affects how you think about the problem, even though semantically it has absolutely no bearing on what's going on.
Osborn: Yes--from the perspective of a book publisher, and [by looking at] our own tracking data, we see that C++, oddly enough is holding its own; it's actually grown a little bit in terms of book sales, whereas VB has declined probably 20 to 25 percent in the last year. C# has been very steady [Ed.: But flat].
Osborn: So clearly, from what we're seeing, there seems to be a migration from VB to C# [Ed.: Or perhaps elsewhere]. But C++ seems to have its niche.
Hejlsberg: Right. VB and C# very much appeal to the same crowd of programmers. C++ does play in the managed space, but C++ at [its] core is really about writing unmanaged code, and a lower level of programming. I know I'm generalizing here, and yes, you can [do] template-based [programming] and [use] STL [Ed.: The standard template library], and I'm not meaning to belittle anything. I'm just saying it's sort of broad position and the broad clientele of C++ tends to write a different type of application than you write with [C# and VB].
Where C# and VB very much appeal to the same segment.
Hejlsberg: So I'm not actually surprised that C++ is--
Osborn: You wouldn't choose C++ to write managed code.
Hejlsberg: Personally, no. I would not choose it to write managed code. But if I had to go write a compiler that wasn't going to be managed code or whatever [, I would]. But I think as a general rule, every year that passes, I think the reasons for writing managed code are stronger and stronger. Simply because the hardware is more capable at this point, and the tradeoff, arguably not very large, but the tradeoff that we make for "Let's sacrifice a bit of CPU power and a bit of memory for dramatically increased productivity," is a great deal. I think it is a very worthwhile value proposition. And I think that's only getting more true. Plus the world of managed code is getting richer every day. It clearly is where all the innovation is happening, and where the vast bulk of enterprise apps are being written today.
Osborn: Maybe we should talk a little bit about version 2.0. Certainly, [C# programmers have been] looking forward to generics for a long time.
Osborn: What's different about the generics in C# as opposed to other languages?
Hejlsberg: I think that begs the question of what's different between C# and Java, obviously.