Sponsored Link •
Anders Hejlsberg, the lead C# architect, talks with Bruce Eckel and Bill Venners about the trouble with distributed systems infrastructures that attempt to make the network transparent, and object-relational mappings that attempt to make the database invisible. The conversation is also joined by Dan Fernandez, Microsoft's Product Manager for C#, and Eric Gunnerson, C# Compiler Program Manager.
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 installment, comments are also contributed by Dan Fernandez, Microsoft's Product Manager for C#, and Eric Gunnerson, C# Compiler Program Manager.
Bill Venners: In an interview on O'Reilly, you said, "When we first sat down to design the .NET framework we took a step back and looked at what's actually happening on the Web. It's becoming this loosely connected, very distributed world, and we tried to understand what that does to your underlying programming model. And so we designed from the ground up with the assumption in place that distributed apps are built in a loosely connected, stateless fashion that gives you great scalability. You just scale out. You roll in more racks and plug them in. And once you make that fundamental assumption, it changes everything." What does it change?
Anders Hejlsberg: The prevailing wisdom five or ten years ago about how
distributed systems would be built in the future was CORBA, IIOP, object request
brokers. The rave at the time was to make the world look like objects, in particular, to
have a bunch of infrastructure that shrouds the fact that objects are distributed. The
nirvana ideal was that you could just say
Object obj =
CreateMeAnObject(), and then call
obj.ThatMethod(), and you wouldn't know if that object was over in
Thailand, right next door, or in the same process. The problem with that type of
programming is: it works great in a single process; it works quite well across processes; it
works fairly well in a small intranet; but then it completely sucks thereafter.
If you hide the fact that messages go across a network, and don't know when they go
across, you end up with chatty conversations. And all of a sudden, the speed of light can
become a big problem for you. You can't engage in a conversation with an object out in
New York that goes,
obj.LetMeGetZ(). No, you need to say,
and have everything come back in one chunk. But you can't really do that
unless you actually make people understand that they are building a distributed
application. In other words, you shouldn't try to pretend that a remote object is just a
local object, because there is a difference. That's one thing that works so well about web
Moreover, web services run on existing infrastructure that we know scales. Web services that run over HTTP are just machine-to-machine communication over precisely the same infrastructure that we all use daily when we use browsers. And we know perfectly well how to scale that. If there's anything we know about scaling up, that's it. So why not leverage that? That's what web services do. Whereas, we know precious little about how to scale CORBA systems in a geo-scalable fashion. We just don't. There's just no knowledge about it, and I've never heard of anyone being particularly successful doing it.