How C# Was Made

prostoalex writes "Bruce Eckel (from the Thinking in C++/Java/Patterns/Enterprise Java fame) and Bill Venners have interviewed programming legend Anders Hejlsberg. After 13 years in Borland and joining Microsoft in 1996, Hejlsberg now leads the development of C# language and talks about the development process, reasons some things exist in C# and some not, as well as future directions."

Comments

Re:"Co-opt Java"

[tjmsquared]

I don't know why Java developers always feel the need to point out that C# took a lot of ideas from Java. I don't see C++ developers always pointing out that Java's mandate was to "co-opt" C++. Of course C# took a lot of ideas from Java (I don't think Microsoft has ever denied this), because Java got a lot of things right. C# also made a lot of improvements (event handling is MUCH improved in C# for example) and is a great language to program in. I think it would be even better if there were a .NET runtime for an OS other than Windows, but the good people on the Mono project are working on that already.

Sun Should Embrace and Extend

[gurustu]

It's very easy for Java devs (and I'm one) to sneer at C# as just another MS ploy to lure people away from quality, but I think that there's no question that C# has some language features that should be migrated into Java.

It's well known that the C# designers paid a lot of attention to Java, but more importantly, it's also quite clear that they also spent a lot of time paying attention to the experience of developing in Java.

So while I might not entirely agree with the uncaught exceptions or the way methods aren't virtual by default, I do think it would be a good idea for Sun to take the lesson from MS, and take what is best about C# and move it into Java.

Re:Sun Should Embrace and Extend

[gurustu]

I've been following the 1.5 release pretty closely for a while now, and it has some excellent additions. I'm especially pleased with the generics, the enumerated constants, the ability to define a method as accepting an undefined number of parameters, and the improved monitoring. The amount of code I'll be able to remove from my codebase will be large.

However, that doesn't invalidate what I said initially. 1.5 isn't a response to C# (well, maybe the enumerated types are), but seems to be kind of orthogonal to C#. It is a distinct improvement to the language, but that isn't the same thing as "embrace and extend". Those improvements don't give Java evangelists the ability to say "The C# language has no good feature that Java doesn't."

I'm also making an argument about intellectual honesty. Java (like any other piece of software) will never flower into its full potential unless the people who believe in it are willing to acknowledge the strengths of its competitors, and then adopt those strengths where it can.

It isn't a sign of weakness to do that, but a sign of strength.

Re:"Co-opt Java"

[tealover]

In a sense, Java was designed to co-opt C++. But co-optinging C++ was not made as a business decision to lock in Sun customers, it was made as part of Sun's vision of "The Net is the Computer" (or whatever they called it).

Sun embraced the internet years before Microsoft and looked out into the future and realized that desktop computing and huge, standalone applications were going to be increasingly replaced by device computing and small, internet downloadable applications would be prevalant.

To that end, they tried to design a language that was simple, that had built-in libraries to handle basic internet protocols and to a large extent, their vision was spot-on and Java was hugely successful.

Without Microsoft spending years trying to undercut them it's very conceivable that Java would be the lingua-franca of the internet right now.

Re:"Co-opt Java"

[prockcore]

Fine with me. A java-like language that doesn't gobble ram like no tomorrow? Sounds good.

As a bonus, Gtk# has the best API I've ever used in a gui toolkit.

Re:"Co-opt Java"

[yomegaman]

What are you talking about? Nobody uses java for "internet downloadable applications", or even intranet downloadable ones. Their vision of thin-client computing was shown to be a pipe dream, to everyone except you anyway.

Re:"Co-opt Java"

[kyz]

Java was designed to co-opt Smalltalk, or at least Sun brand it and bring it up to date.

Think about it... Smalltalk's main points were the single root object heirarchy, the bytecode compilation, and the large runtime library including full GUI. Did C++ have this? No. It was more "object oriented concepts ported to C" - lean and mean, machine dependant and no standard GUI. The C++ generics and the STL weren't standard when Java arrived.

Re:"Co-opt Java"

[matchlight]

But people DO say that Java was co-opted C++, including you and now .. me. Languages naturally progress from those that already exists like every other technology. Why reinvent the wheel and find out that squares don't work... over and over.

Java is taking ideas from C# as well, just take a look at 1.5 with enums, yes I know they existed before C# but I think their existence in C# prompted the move.

I just find it funny that pro-MS people often don't like to hear that C# could even possibly be an evolutionary step off of Java. And unlike older languages, Java itself is still evolving. The .NET runtime concept that works so much better than Java on a Windows machine is something that could exist for Java some day. C# might actually have a legitimately supported OS other that Windows, and although the Mono project is great, it ain't by MS.
I've used both and the both work and they'll both change... for a while ... then another will come along.

I wounldn't try to find religion in a programming language, they come and go too quickly.

Re:oh, and what's the next release of Java have?

[Shados]

Bingo...and in the end, we programmers don't have 1, but -two- improved languages, as they try to improve to each other. MS trying to lock in their customers or not, Sun trying to control java or not...doesn't matter... Now we have 2 languages that try to improve on each other as fast as possible, and we win!

Re:"Co-opt Java"

[malakai]

Those are side issues -- its role as a tool is secondary

Your comment is a fascinating insight into a fanatical mind. You may not yet be as bad as the guy that lives on the corner of my block, with the foil under his NY Yankees basball cap, but the distinction is small.

You've esentially said C# and .Net may be a great language and framework, may make a developers life easier, may generate better application for our clients (internal and external)... but you don't like Bill Gates and therefore any and all points are moot.

Wonderfull logic.

Your prison/Gates metaphor-pun is wonderfully melodramatic as well.

Thanks for play,

Re:Nice language, bad motives

[prockcore]

why trust your development to a language designed to lock you in to Windows? C#, for all its niceities is just a way of getting you to buy more Windows 2003 Server licenses.

C# is just a language, it doesn't lock you into Windows at all. Mono supports the entire C# language.

It's the classes you choose to use that lock you onto a specific platform.

You can't blame C# if people want to use classes that aren't available on other platforms.

Its like saying that C++ sucks because DirectX doesn't work on Linux.

What did they miss about checked exceptions

[21mhz]

I must say he doesn't seem to grok exceptions very well.

Anders Hejlsberg: The scalability issue is somewhat related to the versionability issue. In the small, checked exceptions are very enticing. With a little example, you can show that you've actually checked that you caught the FileNotFoundException, and isn't that great? Well, that's fine when you're just calling one API. The trouble begins when you start building big systems where you're talking to four or five different subsystems. Each subsystem throws four to ten exceptions. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw. And once you aggregate that with another subsystem you've got 80 exceptions in your throws clause. It just balloons out of control.

Well, if you're a Java programmer worth your salt, you DON'T propagate every exception class the underlying modules might want to throw. You make your code catch exceptions rising from below and either handle them or massage them into the exception set your module exports. This is much better for the upper-level users because they want to deal only with situations raised by, and meaningful for, the APIs at hand, and they don't have to care about what would brew beneath.
If you don't want to lose exception stack information, as of J2SE 1.4, you can chain an original exception to your higher-level exception, so that everything would be rolled down nicely in a trace printout.