AddThis Social Bookmark Button

Print

C#: Yesterday, Today, and Tomorrow: An Interview with Anders Hejlsberg, Part 1
Pages: 1, 2, 3, 4, 5

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.

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 where, orderby, and select clause, we turn that into calls to methods called Where, OrderBy, and 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?

Osborn: Yes.

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].

Hejlsberg: Yeah.

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.

Pages: 1, 2, 3, 4, 5

Next Pagearrow