After 13 years with Borland, Hejlsberg joined Microsoft in 1996, where he initially worked as an architect of Visual J++ and the Windows Foundation Classes (WFC). Then, Hejlsberg was chief designer of C# and a key participant in the creation of the Microsoft .NET Framework. Today, he leads the ongoing 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. Check out the entire eight-part interview here.
The C# Design Process: A Conversation with Anders Hejlsberg
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I can only hope that people start to realize by articles like this how wonder the C# language is as well as the CLR.
Java (and the JVM) have been great, but from my perspective – C# and the CLR is much much better. If you are asking why I state that, just read through the articles since they compare C# to Java greatly.
Has anyone else had a problem with the install process not adding the path for the .net SDK? Yes, this is a little off topic but I have just decided to learn c# about 2 weeks ago (first programming language). I just don’t want to have to manually update the Path statement in XP each time a new version gets installed.
Submitted a little too soon.
If anyone has any good recomendations for forums for C# that would be appricated. Sorry, for this off topic post but I just thought that the people who visit this site would be a good group of people to ask.
Dave
You’ll have to manually update your path. There’s two bin directories that you probably want to add. It’s not that hard!:). How often do you think a new sdk is going to come out? There’s only been two. There also might be a vsvars.bat(or something like that) that will update the paths for you. I never used it for the sdk. I think I used it for vc6.0 years ago.
A good place to start for c# forums is http://www.gotdotnet.com. They’ve got lots of stuff there, including forums.
From what I hear the CLR is much easier to target for various languages than the jvm. The java language was designed and then the jvm. There are quite a few languages that target the jvm, but they don’t interop as good as easily as CLR languages.
One of the things that I like about c# in particular over java is the easiness that you can interop with native libraries. It’s just a matter of declaring the function and dll you would like to use, marshalling some data, and then using it, rather than the whole jni which is a pain in the ass. Of course Sun’s strategy was write-once-run-anywhere so they aren’t all that keen on leveraging native code anyway, where .NET has never taken that position. I never understood the hype over binary compatibility anyway. To me it sounds like the same hype people were falling for back in the late 90’s for platform independent look-n-feel.
Here is a good C# community to ask questions:
http://gotdotnet.com/Community/MessageBoard/MessageBoard.aspx?ID=6
HTH.
Thanks a lot!!!!! I did edit the path myself, no it isn’t hard at all. I have been doing that sence DOS and had already done it. It just suprised me that it didn’t do it with the install. Just an inconvenince, no real huge deal. Also just curious if other had the same thing happen. I will check out that message borad too. Wish me luck.
Dave
I think you mean MFC and not WFC ….
(is Hejlsberg transfer from Borland to MS explain why Delphi is getting worse and worse and .Net is getting more and more interesting ?)
I think WFC is correct, because that’s what the Java version was called if I remember correctly.
In page 3 of part IV, Anders Hejlsberg complains about C++: “One way it could do this is cast the key parameter to IComparable and then invoke the compareTo method. […] If the passed key doesn’t implement IComparable, you get a runtime error.”
I believe, if you use IComparable& keycomp = key; in the template, the type check will be made at compile time, so there will be no runtime error. Thus, you can have the compile-time check equivalent to C#’s “class List<T> where T: IComparable” in C++ as well.
static_cast<IComparable&>(key) almost does the same thing, but if IComparable is derived from other types, then static_cast also allows downcasts from those types, which wasn’t wanted here.
The alternative dynamic_cast<IComparable&>(key) would indeed check the interface at run time and throw a std::bad_cast exception on error. I suppose this matches what you’d get with a non-generic C# List and explicit casts, too.
In page 3 of part IV, Anders Hejlsberg complains about C++: “One way it could do this is cast the key parameter to IComparable and then invoke the compareTo method. […] If the passed key doesn’t implement IComparable, you get a runtime error.”
I found that quoute in part VII. But I think it is about C#, not C++. He writes: “And in C#, you can of course do the same thing. […] cast the key parameter to IComparable and then invoke the compareTo method.”
I agree with Anders that no value types would hurt performance really bad. But the answer is not necessarily a bifurcate type system. Eiffel has shown that you can integrate value and reference types and have a single uber-type as well.