Slashdot Mirror
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."
There a great interview with The father of C# here too,
There is a pretty good interview on the .NET show on MSDN with Anders too. It runs about one hour, so get a comfy chair.
Joel Spolsky published a great article a while back on .Net, his company's strategy for the platform, and why Anders so damn cool. Also, just in case you're curious as to how his last name is pronounced, it's pronounced hells-burg.
iRooster, the Mac OS X a
...right here to save you a click thru the MSDN page.
The Army reading list
Actually, Java supports both checked and unchecked throwables: the latter with the class Error. My programming style is to make throws that I don't expect to be "routinely" caught throw Errors rather than Exceptions. An Error can still be caught, but since you don't expect it, you needn't declare it.
The checked exceptions are still useful for the case where it would probably be a bug not to handle the exception, e.g. "search found no element" or "file not found". The reason for the two kinds of throwables is exactly this: you don't want to declare that every method doing division throws DivideByZero. Unfortunately, the Java library designers don't seem to have gotten it, and so there's a bunch of things like IOException that IMHO should have been Errors.
...uhmm
Go here and when you done, go here and get it.
When you are done playing, come back and see if your post makes sense.
Never by hatred has hatred been appeased, only by kindness - the Buddha
I think on many issues, Hejlsberg is missing the point and the reasons he gives aren't necessarily the actual reasons why particular design tradeoffs are good ones.
.NET) may turn out to be the free and open language that Java should have been; time will tell.
But it really doesn't matter. The changes that C# made relative to Java are obvious and proven (e.g., value classes, removal of statically checked exception declarations, declared unsafe code sections). Many of them had made Sun's bug parade. All of them had been in other languages before either Java or C#. In fact, C# is, in many ways, close to Modula-3.
There seems to be another reason for some of the design decisions: patents. Sun has patents on several aspects of the JVM and Java, and if Microsoft wanted to be free of potential future claims by Sun, they had to avoid those in their own competing virtual machine.
Keep in mind that Hejlsberg is also a salesperson for the language anyway. That means that he may not be telling you the real reasons behind design decisions, but the reasons that sell the language well.
In any case, however it came into existence, C# is a somewhat better language than Java, and we should be happy about that: whether you are planning on using C# or not, it raises the bar for what is considered standard in industry. Without C#, Sun probably wouldn't even have made the largely cosmetic changes they made to Java in 1.5, and maybe the continued existence of C# will force them to fix other misfeatures of Java and the JVM in future versions. And C# (but not
C++ is the opposite. In C++, you can do anything you damn well please on a variable of a type parameter type. But then once you instantiate it, it may not work, and you'll get some cryptic error messages. For example, if you have a type parameter T, and variables x and y of type T, and you say x + y, well you had better have an operator+ defined for + of two Ts, or you'll get some cryptic error message. So in a sense, C++ templates are actually untyped, or loosely typed. Whereas C# generics are strongly typed.
// . . .
I disagree with that assessment. Both C# and C++ generics/templates are strongly typed. It's just that the enforcement happens in different places.
In C++, if you try to stick a class into a templated class when that class doesn't have a particular member function defined, the compiler will yell at you, just like Hejlsberg said. But for some reason, this doesn't count as type checking? Yes, template error messages can be strange (and very long) if you're not familiar with them. But that's just a lesson in "know your tools."
To me, "strongly typed" is strict type enforcement at compile time. C++ templates certainly do this.
Constraints, however, are something that I think are a generally good idea. Stroustrup's reasoning for not including them in C++ was that "Requiring the user to provide such information decreases the flexibility of the parameterization facility without easing the implementation or increasing the safety of the facility." (The Design and Evolution of C++, Stroustrup, 343).
He does, however, show an interesting way to get around this using inheritance:
template <class T>
class Comparable {
T& operator=(const T&);
int operator==(const T&, const T&);
int operator<=(const T&, constT&);
int operator<(const T&, const T&);
};
template <class T : Comparable>
class vector {
};
(The D&E of C++, Stroustrup, 344)
This technique is similar to how C# does constraints, class List where T: IComparable. One is supported and enforced by the language, the other is a natural consequence of the languages facilities. In general, I think that constraints are probably a good thing. Having an error message like "Can not instantiate class Y<T> because T does not implement z()" is probably best, and when looking at a class' declaration, it would be nice to see up front what assumptions the templated class makes.
In your example, I know with complete certainty that I am creating a new "Type" and assigning it to the variable "varName". This is not the case if it used the syntax of Python. How do you know I am not calling a method called "Type"?
You don't know, and you shouldn't.
Suppose at first you do, in fact, instantiate a new object via the 'Type()' call. Later, during the optimization phase, you discover that in most cases you can return a reference to a pre-existing, pooled object. In Python, you can make that change without breaking client code; not so when object creation is explicitly annotated.
As to whether Type is a method, function, or class constructor, it doesn't matter as long as the returned objects implement the required interface.
Erlang.org: wow
Here's your macro: http://weblogs.asp.net/jan/archive/2003/04/29/6168 .aspx
There are plenty of people working on tons of free libraries out there. The gotdotnet workspaces are pretty good place to search for things, but your best best is to follow the weblogs on asp.net.
Ever bothered to look at http://www.codeproject.com ??
How about you write your own getter/setter macro and publish it there ? That is how a community is built, slowly but surely.
Intelligence shared is intelligence squared.