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."
I believe that was the mandate given Hejlsberg by Gates.
-- You see, there would be these conclusions that you could jump to
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
Microsoft starts trying to tell people that "OO is soo... yeasterday. You want Indigo."
You're referring to Don Box, specifically, right? I don't think it's so much that Don is pooh-pooh'ing OOP in general, it's that he feels that a service-oriented architecture is better suited to the kind of problems we face today than DCOM or CORBA. His point is that trying to use an OOP metaphor for enormous, architecturally sound remote object invocation/data transfer systems is a terribly complex task.
Also, keep in mind that Don wrote *the* book on Microsoft's COM technology; OOP has its place, but CORBA and DCOM are not really the place.
iRooster, the Mac OS X a
They hit the black key to the right of C.
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.
It seems to me that big companies like Sun and Microsoft like pseudo-compiled languages like Java and those in
1) Pseudo-compiled languages are easily decompiled. If a small competitor writes an especially useful program, it is easy to see the logic by just decompiling the source code. In business programming, the business systems logic can be EXTREMELY complicated. It's easier to copy it from a competitor who has proven success. See these links for information about decompilation. Of course, the best methods of decompilation are not made public:
Java Decompilers
A friend wrote this:
"I regularly use decompilers for Java classes. The last library I decompiled is TupleSpace from IBM, a library for network communication (useful if doing clustering). The result was of a shocking clarity.
"That was especially easy because the code had few local variables (in the bytecode, local variables have an identifier that is a number) and no obfuscation."
2) Pseudo-compiled languages are slower. That raises the cost of hardware. Sun makes most of its money from selling hardware. Slower software requires more expensive hardware. Microsoft makes most of its money selling operating systems. The customers most important to Microsoft are not you and I. Microsoft's important customers are the systems builders like Dell and HP. Systems builders want slow software so they can sell more hardware. Microsoft wants slow software so people buy more systems and therefore more operating systems licenses.
C# may not be that great compared to C++ or Java. But what .net provides is pretty nice.
.net is partially supposed to be...all thanks to Mono.
My officemate wrote a function in vb.net on a Windows box, running via ASP.NET/IIS/Win2k. I wrote a small little C# program on my Linux box that calls the procedure on the windows box. It looks something like this:
result=addup(2,5);
with 7 being put in result. Nice and simple. Could have easily been something to add a user to a box...or I could reimplement the same function on my Linux box to add a user there and he could call it from an vb script.
It does a great job of providing cross platform calls without adding tons of overhead or a lengthy API...the libraries do all the setup/teardown instead of the programmer, and it is a lot cleaner than parsing html output.
It may not be perfect, but I'm just sporting a woody because I finally somewhat understand what the hell the nebulous
Having used TP and DelpiI was kind of disappointed to see Anders join Microsoft a few years back. But now behold .... Delphi 8 adopts quite nicely to .net and is actually giving Borland a new lease on life and delivering where Kylix couldn't.
Having used both java and delphi I allways missed some sort of generics. I found Anders thoughts to be quite interesting. Question: is it possible to change the java generics-implementation in such a way that it would loose the limitations mentioned (and changing the JVM in the process offcourse)?
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.
For fucks sake, man! Wake up and smell the marketing bullshit. The most innovative impressive thing about Java was that it was successfully marketed as basically the second coming (more tangibly as the solution to 10 different huge problems), all while just being another platform. Get it? They created their own platform without hardware leverage, OS leverage, app leverage, etc. It's bootstrapping by marketing.
In many cases, pseudo-compiled languages, or languages that use a VM are a better choice. No worrying about memory management, buffer overflows, etc.
There will always be a place for C and C++ in places where you *NEED* low-level control over things like memory management, or where performance is very critical. But for most applications, this is simply not the case. You want a language that can do all you need it to do, and you don't want to worry about the rest of the details. Java and C#/.Net are the next big thing in commercial programming. But they certainly won't be the last. There will be another language that is better in 10 years from now. But right now it is a good thing that we have two choices, instead of one. Competition is a *good* thing.
Well, pseudo-compiled languages is hardly a "big company" thing. Look at Python for instance. It's all over the place (in the open source world).
I remember when legal used to mean lawful, now it means some kind of loophole. - Leo Kessler
I think the old adage needs to be updated: If you want to eat sausage, obey the laws, and use C#, you should never watch them being made.
...
Another one? But I haven't finished Brockschmidt yet! :)
One line blog. I hear that they're called Twitters now.
> it is easy to see the logic by just
> decompiling the source code.
You mean bytecode, probably.
> the business systems logic can be
> EXTREMELY complicated
If it's that complicated, having a bunch of decompiled source code is not going to be that useful. You're better off programming it yourself so you understand it and can change it when you need to.
> Pseudo-compiled languages are slower.
But not _much_ slower. A $3K dual CPU Linux server can serve up a lot of Tomcat hits. Need more? Buy a load-balancer and a few more servers. Not a big deal.
The Army reading list
That's the biggest FUD I have seem so far. Your talking about "pseudocompiled" makes me think you don't know how either language really works.
OTOH I agree that both are relative simple to decompile.
The speed will depend of your particular use, but in some cases programs in Java are faster than C programs.
"I think this line is mostly filler"
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.
Your 4.5 is wrong, and even in a world in which it made sense, it'd still be wrong. Sun's whole marketing mantra around Java was "Write Once. Run Anywhere." Allowing platform-specific extensions would break that, so it's an obvious non-starter. Sun's reaction wasn't correct, but it was an allowable one.
.NET is usable, but Java is something horrific.
.NET-bashers never get modded down but anyone who dislikes Java goes to karma hell, LOL...
I wonder why
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!
Gonna burn some karma on this...
;) And yes, I am just teasing.
Gandalf: This is C#. Forged by the Dark Lord and his engineers in the fires of Mount Redmond. Taken by him from the hand of evil himself. All who use it are bound to him. Gates needs only this ring to cover all the lands of a second darkness... He is seeking it, seeking it; all his thought is bent on it.
Frodo: Alright, we put it away. We keep it hidden. We never speak of it again... No one knows its here, do they? Do they, Gandalf?
Gandalf: Unfortunately, yes. The power of Gates is far reaching. The innocent would use C# from a desire to do good, but through them, it would wield a power too great and terrible to imagine.
You get the idea...
*-*-*-*-*-*-*-*
"We are Linux. Resistance is measured in Ohms."
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
1) Pseudo-compiled languages are easily decompiled.
Um, compiled languages are easily decompiled as well.
http://hte.sf.net is a badass hexeditor/disassembler.
Case in point, I walked through the assembly of iTunes to figure out the AES key that iTunes uses for iTMS. And iTunes was written in C++.
But say it was. Who cares? Every language is based to some extent on what came before it. The question is, does it improve on other languages? Does it have a niche that it serves better than other options?
In this case, the answer is yes. Java is horrible kludgy in a lot of ways, and yes, it's horribly slow for large applications (although, small benchmarks can hide it's slowness). And no, I don't want to debate yet again the merits of Java. I think it sucks. If you think otherwise, more power to you. I'm glad it works for you.
Sometimes it's best to just let stupid people be stupid.
most serious C# drawback is that it doesn't have (and probbably will never have) so rich and wide open source community like Java does (Apache group, Object Web group and many many many more...).
:-))
Each tiny crappy component, each crappy lib for C# out there on the net is sold, and sometimes for outrageous prices (a month ago seached for a plugin to generate properties from variables - something like getter/setter generator macros, so common in most Java IDEs - found it for 100$ per seat! OMG!). there is no idea of sharing, neither the source nor experience, and this IMHO will be the main cause of C# setback.
And oh, most computer literate people pronouce '#' as 'hash', not 'sharp'
The truth is - existing software quality sucks. There are a few exceptions, but there are too many poor quality products being shipped everyday sometimes costing millions of dollars. The fault is seldom with the tools or the language of choice.
There are so many parts of the whole software development process that needs to be improved. With the right process, people and management it is possible to make great software regardless of the language.
When automobile engineers argue, do they argue about the quality of their cars, their features and design or do they childishly bicker about which wrench is better?
All your favorite sites in one place!
One thing I've never seen explained in any of the designer interviews on C# or Java is why they both have the redundant 'new' keyword.
Neither language allows you to create objects on the stack, so using new to denote 'on the heap' is completely redundant.
Also, why can't language designers take hints from the *productive* languages as well as the *popular* ones.
I'm not saying that good programming is a speed typing contest, but modern, popular languages require far too many key presses to get stuff done.
C#/Java
Type varName = new Type(args);
Python:
varName = Type(args)
Want static typing? Why not type inference like OCaml?
Damn them.
Unfortunately, Java gets most of these features at a superficial level, since it has to support older VMs. Sun sees that C# has these things and that developers want them, so they give them as much of the syntactic advantage as they can without "breaking" their older VMs... its really a shame.
.NET development framework, and now I can use it on UNIX based systems. I am still waiting for a nice release that will fully run on Mac OS X though.
The Microsoft CLR has support for many of these features (and others) built into the underlying framework. As a result, things like Generics in C# are about a hundred times as functional and advantageous than they are in Java. Read the article that was linked to in this story, and it will readily become clear that Java is playing catch up at this point. The C# creators really thought of these things *up front* and designed the framework for them, and it really shows.
One of the best examples of this in the interview is that of generics. In C#, if you declare a List of Customers (List), you can see that all the way down to the Reflection/introspection level. It really, genuinely is a List of Customers. However, in Java, because they have to live with their inferior framework, a List of Customers at the Reflection level is a List of Objects... hence, its just an illusion. You get the type checking at compile time, but lose performance advantage and true Generics support.
Thank God for the folks at Ximian though! I really like much of the
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.
There is history before java that matters too; Such as Microsoft had its own processor independant P-Code compiler nearly a decade before java, but kept it private probably as a competitive advantage. This is a cold irony.
Microsoft was worried about java even before it became popular; for the simple reason that if a portable internet language did become popular, it would obviate the need for windows.
Microsoft did not get their hat handed to them when they attempted to co-opt java: seems to have worked nicely.
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.
My exception safety is -fno-exceptions.
I guess you've not heard of gcj, TowerJ or the other traditional ahead-of-time compilers for Java, eh?
Java is not necessarily a VM based language - that's not to say that VMs aren't useful in lots of situations. Obfuscators also often work well. Of course, if you're doing server-side code, decompilation isn't an issue at all...
Nice straw man though... ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
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
You should be much more careful with 'nobody' word.
As my first-hand experience I can say that we use Java for both server and client side for corporate software and yes, it's downloadable application. Excellent solution if you ask me, trivial to update, secure, portable and very nice environment for developers too.
You would then have something like this in Java:
Type myType = Type.new(); //invokes Type's static new() method
And of course you should feel free to override the implementation of new(), just like you would do it in any constructor. No more need for messy super()... Oh but static methods in Java can't inherit behavior? Because classes aren't considered as objects? Doh! How very object-oriented... (end of sarcasm)
In any true object-oriented language, you should be able to write almost everything as object.method(argument), and this is not the case with Java unfortunately...
"In our tactical decisions, we are operating contrary to our strategic interest."
AIUI, the major reason many of the big names in C++ don't like language-supported constraints on type parameters is that just having "derives from this base class" isn't a sufficiently general condition for good support of generic programming.
C++ enforces any necessary interfaces at compile-time, by checking whether the instantiation of a function template can be interpreted properly with the functions available. Requiring every class that supports == to derive from EqualityComparable is just a cumbersome extra for no benefit in a generic, C++ based world, where there are more ways to define and implement interfaces than just inheritance. If it doesn't support ==, the function template will fail to compile at the point of instantiation anyway. (OK, strictly speaking export messes up the compile-time/link-time distinction slightly, but the basic point is still valid.)
Incidentally, it is possible to use template wizardry in C++ to enforce various plausible constraints on type parameters if you really want to restrict them more than their usage within the function template does anyway, perhaps to guard against a possible misinterpretation of the template code in some cases. It's relatively straightforward to do this, and requires little more code than the formal constraints used by some of the other languages under discussion.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Now we only need for Anders to write an article explaining why Spolsky is such a jackass...
most serious C# drawback is that it doesn't have (and probbably will never have) so rich and wide open source community like Java does (Apache group, Object Web group and many many many more...)
.NET components. .NET and C# are two entirely different things. There is a lot of open source C# software out there (check go-mono.com).
.NET APIs implemented, and, additionally already has a complete set of open source toolkits and libraries, with APIs that, unlike the Java stuff, are already familiar to existing open source programmers.
It is true that there is more open source server-side web stuff for Java than there is for C#. But, against that, you have to hold that C# actually has a full-featured, high-performance, compatible open source implementation. Also, you can get a full-featured, open-source, widely-used GUI toolkit for C#, namely Gtk#.
And all that open source Java stuff doesn't really matter as long as Sun owns key parts of the platform (e.g., the Swing implementation). Yes, you can exchange open source Java libraries all you want, but Sun has ultimate control.
Each tiny crappy component, each crappy lib for C# out there on the net is sold,
No, it isn't. You are thinking
What you should really be asking if you are interested in open source is: if I only use open source tools, how do the two software platforms compare? And if you only use open source tools, Java looks like a pretty sad platform: you can choose between Kaffe, orp, and gcj as runtimes, but none of them are anywhere near complete and most open source Java libraries don't run on them. You can't even get a working open source Swing implementation. In comparison, C# is much further along: Mono has a lot of the
Wasn't it just done by covering one of the holes and blowing down the tube?
If you remember what happened a while ago, the story goes: Microsoft was facing competition from Borland, so they hired away all their lead developers to break the company's neck.
It almost worked.
PS: Don't use anything that has a '#' in it and isn't music!
There are people besides Gates who might disagree with your opinion of goto. Read what Steve McConell has to say in his -balanced- portrait of goto: http://www.stevemcconnell.com/ccgoto.htm
Notice that one of goto's defenders (for appropriate circumstances) is none other than Don Knuth.
I generally avoid goto like the plauge... but sometimes it's the right tool for the job.