Rob Pike has done some really cool stuff, but he's also kind of a weirdo. He doesn't believe in putting any "#include" directives in ".h" files. He says you should figure out what the dependencies are and put all the includes in your ".c" file.
How is it "just a compiler hack"? They had to modify the CLR instruction set to allow for type parameters. The underlying machine code is not the same. For reference types, the dynamic type check (which is really slow) is no longer neccessary. For value types, the code is definitely different since they'll deal directly with the values instead of dealing with them through boxes objects.
How can you claim not to care about performance at all? C# gets rid of the tedious casting and runs faster than Java. With value types, the performance difference even greater and allows programmers to use the collection classes in cases where they'd normally be forced to use arrays and do a lot of extra manual work. There is no downside. As a matter of fact, Java's downside is that you can't use generics wherever you want because the VM doesn't know about generic types and can't properly handle all the dynamic casts.
You seem to imply that the VM can be crashed by bad bytecode. This is not the case. Even though the VM has a simpler type system than the Java language, it is still type-safe. The main disadvantage to Java's approach is efficiency. In Java, the VM needs to check the type dynamically on every access. Also, the primitive types have to be boxed, creating a lot of overhead in both space and time.
The other disadvantage is the lack of orthogonality. Though type erasure is perfectly OK for languages that don't rely on the ability to perform unsafe casts, C# and Java programmers use do use some weak typing and therefore depend on the ability to perform type unsafe casts. The Java compiler issues warnings for cases where a type error will not be detected as early as it should be, limiting what you can do with unsafe casts. In C#, the extra type information lets you use unsafe casts to your heart's content.
And how many more job openings are there for Java than there are for PHP?
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 5, Informative
C# vs Java, mostly a tie (c# good: ref and out parameters, indexers, foreach; c# bad: properties, operator overloading)
While 'ref' paramters are debatable, 'out' parameters are stupid. They should have created a way to return multiple values from a function. Allowing first class tuples would have been the correct way to do this (in most C-style languages, tuples are allowed as arguments to functions and disallowed everywhere else). Adding tuples would also have eliminated the need for the hacked up delegate functionality. Then again, Java doesn't have any equivalent functionality, so it could be seen as an advantage for C#.
Operator overloading is a good thing. It can be abused, but so can anything else. Removing operator overloading doesn't even come close to making it impossible to write obfuscated code. There are many situations where operator overloading makes things a lot simpler.
Properties are also good. Instead of identifying them through string matching ("get*", "set*"), language-level support for properties allows more accurate data type modelling. In the end, however, the CLR doesn't really have true support for properties. They implement them as methods (like Java, except at a lower level so most programmers don't have to care about it). This implementation mistake resulted in different opcodes for field access and property access, which means you cannot switch between fields and properties without changing the class's public interface (and breaking binary compatibility with client code). It's still better than what Java does...
Function pointers and anonymous functions. This has got to be the biggest improvement over Java. Unfortunately, class libraries were already designed before the anonymous function feature so they probably wont be designed to take advantage of it. Also, VB and C++ are probably holding things back because, as everyone knows, "language agnostic" is just a euphemism for "lowest common denominator".
You also forgot generator functions. They make it easier to write pull-style classes (a "pull" XML parser, for example). Though it isn't as powerful as full-blown continuation support, I think it'll still be useful for many coding tasks.
C# has more comprehensive generics support (aside from variance). Though both languages made the mistake of allowing arrays to be fully covariant (ArrayStoreException), Java got screwed when they decided not to maintain dynamic type information for generic type parameters. This limits the use of generics in often confusing ways. Type erasure isn't a problem in languages that have a good enough type system to avoid resorting to dynamic typing (like ML or Haskell). But C# and Java do not have good enough type systems and the C# people recognized that and chose to keep the dynamic type information around.
C# is better than Java in almost every way. Java has better enums and support for covariant and contravariant generic type parameters, but that's about it.
I wouldn't consider the Wikipedia to be a definitive source, especially for such an often-confused term. For all I know, you could have written that entry. Things I "learned" from that entry:
"Suppose that a strongly typed language (like Pascal) didn't have garbage collection..."
"...garbage collectors are best implemented in languages that allow pointer arithmetic."
Garbage collection is the only form of automatic memory management.
Look at entry on typed and untyped languages. It says that Perl is weakly typed. But you can't escape the Perl type system and cause a crash which means (by the other entry's definition) that it is strongly typed. So, apparently, some Wikipedia contributor doesn't agree that the two terms are equivalent.
About half of C#'s "advantages" are capabilities that the designers of Java considered and rejected as being a bad idea (by making the runtime less stable and secure, unnecessarily complex, etc. -- I knew Guy Steele at the time, and he certainly was aware of operator overloading, generics, etc., and made the (smart, IMO) decision that it was more important to make the language,compiler and JVM (and security model) simpler, smaller and more predictable).
Sure, Guy Steele is smart, but that doesn't mean he he never makes mistakes. At the time, the Java designers tried to eliminate unnecessary complexity, but it's hard to decide what "unnecessary" means without seeing the language in action. He now seems to think otherwise about generics and operator overloading (if, in fact, he originally thought they did not belong in Java), probably after seeing the collections and BigInteger in action.
You haven't made any specific arguments about how the features add unnecessary complexity and make the runtime less secure, but here's what people usually say:
"Operator overloading can be abused." Yes, it can be. But it doesn't have to be. There are ways to write obfuscated Java programs with the 1.0 language spec. You cannot eliminate obfuscated code. You just have to set a good example with the standard class libraries and use operator overloading only when it makes sense.
"C++ templates are really complicated, so generics must be really complicated." Generics are much simpler than C++ templates. They don't bloat the code, they use explicit constraints to make error messages more sensible, and you don't have to ship template classes around in source form. I don't know why you mentioned generics, though, since Java 1.5 has them.
"Unsafe code compromises the safety of the system." Yes it does, but that's something the developer is aware of. The safe subset of the CLR instructions is just as complete as the entire JVM instruction set. Unsafe code is meant to be used as an alternative to some of the cases where you were forced to use JNI. Unsafe code is portable in compiled form, unlike an application that uses JNI.
What C# design mistakes make it worse than Java? Though I think value types were a mistake, Java doesn't really have a better way of handling them right now. I also mentioned that Java has better enums and variant typing. That's all I can think of (please respond if you can think of any more). Those advantages don't outweigh C#'s: function pointers, closures, generator functions, fast generics, isolatable runtime contexts, etc. C#'s improvements over Java probably won't make it worth your time to port your application, but there's no question that it is, overall, a better language.
Industry Support
Yes, Java has more industry support and more industry support is definitely better. However, there's a threshold after which you can safely use a language without worrying about tool support or the variety of available libraries. It's not a well-defined line, but C# is definitely going to cross it very soon. For many developers, the current level of support is probably good enough.
How does Java have better desktop platform penetration? It doesn't come with Windows either. Some OEMs might pre-install the JRE, but those OEMs are probably just as willing to pre-install the.Net runtime. While Longhorn wont be out for a while, it will be preinstalled by all the major desktop vendors when it does. It's not likely that Solaris (or any other OS that comes with Java pre-installed) will have a significant share of the market. It could happen, but it's a sensible decision to bet on Microsoft winning out again.
Companies that want uniform environments are willing to pre-install MS Office and Adobe Acrobat on all employee desktops. Why wouldn't they be willing to make the free.Net runtime part of the standard installation?
In strongly typed languages, type safety is enforced, with no loopholes. Both ML and Java meet this criterea.
You are confusing typing strength with type-safety.
For example, you can have a crash-proof implementation of BF. Does that make BF type-safe? Yes; the type system is so pathetic that it's trivial to enforce type safety. Does it make BF strongly typed? No, because the type system doesn't do a good job of accurately describing the values you compute on. Tcl is also type-safe, but, again, the type system is weak (strings and lists are all you get).
Perl is often cited as a weakly typed language because strings and numbers are easily interchangeable. But this doesn't make Perl type-unsafe. Type-safety is enforced; it's just that there is a type called "scalar" that can handle both strings and numbers by design. Perl is weakly typed because many other languages make the distinction between strings and numbers and therefore more accurately describe values.
Type-safety means you cannot escape the type system. Strong typing means that your types are very precise descriptions of your values (relative to other languages).
Some examples:
Language | Safe | Typing Strength
Tcl . ..| Yes. | Pathetic.
C . . ..| No . | Weak. Lacks subtyping, among others.
Old Java | Yes. | Medium. No parametric polymorphism.
New Java | Yes. | Strongish.
C++ . ..| No . | Strongish.
Haskell.| Yes. | Strong.
Epigram.| Yes. | Insanely Strong.
BTW, Python shouldn't really be considered strongly typed. The typing is weaker than Java's. Method invocations and field accesses are performed through string lookup.
// weakly typed: x = GetElevatorButton(); x.Press();
// strongly typed (not real Python): x = GetElevatorButton(); x.[ElevatorButton]Press();
The strongly typed version ensures that you're invoking the method you think you're invoking instead of invoking a method that simply has the same name. Python will not notice an error if GetElevatorButton() returns a BellyButton instead because method invocations are done by matching strings. Of course, the stronger typing doesn't really work well in a dynamically typed language. (Then again, dynamic typing is just a fad that will fade when people realize that what they really wanted was type inference).
why on earth should anyone care that there's something that's almost Java, only without anywhere near as much industry support, and many years less maturity?
C# is better than Java in almost every way:
C# has function pointers (delegates) and closures (this is the biggest draw for me).
The CLR's generics implementation is more efficient. Java's ArrayList<Integer> is painfully inefficient.
The CLR's generics implementation is more complete because it retains runtime information about type parameters. Java's generics has some limitations ons what a type parameter can be.
C# has better virtual method annotation syntax; non-virtual by default, explicit override, explicit shadowing.
C# has a simple way of making sure you dispose resources.
"unsafe" mode. Now you can stay in C# for many tasks that you used to have to write C code for. Unsafe code is platform independent.
This is more of a CLR thing but Java really needs an AppDomain-like isolation facility. They're working on it, but it's a little late now.
You may hear about these "features" from pro-CLR people:
Value types. These are bad. They just fragment the type system. A good compiler can figure out how to speed things up requiring that you mess up the type system.
Language agnostic. This is not true. How are you going to call overloaded functions from C? What about dynamic dispatch on parameters? The API is very C++/Java-centric and will have to stay that way. The CLR does have slightly better interoperability, though.
The only advantages the Java language has (that I can think of) are:
Flexible variant typing.
More powerful enums.
It's true that C# is mostly copied from Java. They didn't add any novel ideas. They just improved it incrementally (and screwed up a little too). But after everything is accounted for, it's clearly a better language. You can talk about "maturity" and "industry support" all you want, but some people are just happy to be using a superior language.
BTW, both "maturity" and "industry support" wont be problems for C#. It's not hard to design a mature language and set of class libraries when you have a working example to learn from. Also, Microsoft has mature designers working on the CLR and that counts for something too. As for "industry support", you have got to be joking. When they make the CLR come pre-installed on Longhorn, it will instantly become an industry standard. Even now it's available directly through Windows Update. The whole XAML/Avalon thing is not even ready yet but Amazon.com has already used it to build a prototype. It's depresing, but true: anything that comes out of Microsoft will have a completely unfair advantage over any competing products. Macromedia is next.
A lot of people have been saying that the interview disparages CVS and SVN without details. I didn't get that impression at all when reading the article.
I think the difference is that I've recently begun reading a lot about version control and have come across the issues he's mentioned. This is just a case of him assuming too much.
About the cvs-just-totally-sucks comments, I don't think they're way out of line. If you look at it from the perspective of a person who just started using CVS, then you may not think CVS sucks because you're comparing it to the no-version-control system. But if you look at it from the perspective of someone who is developing a version control system, CVS is really lacking.
The problem with SQL is that you have everything built into the one program. Pipelines allow you to bolt functions together in an unanticipated order to create complete program concepts without writing any glue code.
Pipelines aren't the only way to pass data between separate programs. Sometimes the linear nature of pipelines makes some tasks less straightforward than it could be. The functional programming people have no problem combining the primitive operators to perform complicated operations (and you don't need glue code for that). The main motivation for relational databases was that they let you query your data in unanticipated ways.
I don't think pipelines are bad; they're really convenient for many tasks. But if the Monad guys are going through all the trouble of enforcing types on the data, they could take better advantage of the more powerful constructs that such typing allows.
With SQL, you don't have "everyting built into one program" (do you know what SQL is?). Individual queries aren't necessarily tied to each other. The extensibility comes from the fact that you can transform tables in arbitrary ways. You can write a "commandlet" to generate whatever kind of table you want.
I'm not suggesting that you'll need all the stuff a database gives you (keys, triggers, etc.). It's just that the RDBMS people have come up with good ways of dealing with tables and it would be a good idea to try and incorporate some of that.
It's great that they're trying to do something at a higher structural level. The Unix command line data structure is essentially just a sequence of '\n'-terminated lines. But while it looks like each filter command is doing its own thing (where, sort, group, etc.), they're really just doing the equivalent of an SQL 'SELECT'. I wonder why they are forcing the Unix-style pipeline syntax instead of a syntax that maps well to the relational model.
I really don't understand how you can argue against autoboxing. Can you honestly say that your first code snippet is not clearer than your second? Also, your example was unnecessarily long and just hurt your case. You could have written:
int i = e.next().intValue();
But that still has an unnecessary method call that autoboxing will eliminate.
...you want to change its value and you cant do that with an automatically boxed type:
e.next() ++;
will simple not do what you intended so you will have to go back to casting Integers again. now THIS mixed use of two different methods will make you coding unreadable.
The example doesn't work because the "++" operator only applies to storage elements (like variables and arrays). Ever tried doing "System.currentTimeMillis()++"? Java programmers are used to this because the collection APIs were never totally transparent (i.e. they never were as concise as array access); the Java language (like some others) doesn't support it because, unlike values, storage elements are not first-class.
You don't have to "go back to casting Integers again." Going back to casting integers gives you nothing, because java.lang.Integer objects are immutable, just like int values. If all you have is an Enumeration or an Iterator, then you can't swap out elements of a Collection object. If you have an array, then I doubt you'd be taking advantage of autoboxing anyway. If you were using an ArrayList then compare the autoboxed way:
list.set(index, list.get(index) + 1);
...to the old way (without even using the unnecessary cast that you, for some reason, decided to insert).
Integer i = list.get(index); Integer j = new Integer(i.intValue() + 1); list.set(index, j);
Even on one line, it's less readable:
list.set(index, new Integer(list.get(index).intValue() + 1));
Here, autoboxing can eliminate two conversions for you (one on the get and one on the set. I just can't understand why someone would want to explicitly write out the mechanical conversions that a compiler can perform for you (with 100% accuracy).
If object-pooling is a prerequisite for a good program, then the runtime system isn't doing it's job. It is a pain to perform object pooling and you have to design your objects differently if you want to allow them to be pooled.
It would probably be a better idea to attach attributes to classes to provide hints about how they're going to be used. That way you don't have to actually change the way your program works to reap the benefits of pooled objects. Make the VM do it for you.
A lot of the time, a generational garbage collector can handle the deallocation of many short lived objects efficiently. In the canonical copying collector implementation (a generational GC is a copying collector) allocation is extremely cheap too (just incrementing a global variable) and has a good chance of being much faster than maintaining a weakly-referenced free list object pool.
Java is not supposed to hide pointers from the developer. Haskell accomplishes such a thing, but it also doesn't allow side-effects. If you want to allow side-effects (i.e. mutable shared variables), hiding pointers is much more difficult.
You may decide to call them "references" instead of "pointers" but they're essentially the same thing. It's just that Java doesn't let you perform arithmetic on them.
Referential equality can be useful and so there's reason to give a programmer access to it, but value-based equality comparision is the common case and probably should have been assigned to the '==' operator. One reason they may not have done so is to avoid hidden complexity. In C, for example, you can look at a chunk of code and get a good sense of what's going on. In C++ (which is an extreme case) a chunk of code that looks simple might be doing a bunch of other crazy things using operator overloading and automatically-invoked destructors.
As for your comment about this "making no sense"... It makes sense when you realize the '==' compares the values of variables and does not go the extra mile to dereference pointers and invoke comparison functions. While it may have been a good idea to do all that extra stuff, the current semantics are not confusing.
I always assumed it was the difference between the language and the platform
The Language is Java 2, the platform is J2SE 1.4...
I think that was the original story, but that doesn't make any sense either. The language has changed, but they kept calling it Java 2.
Originally, they seemed to be actively avoiding increasing the the major version number. JDK 1.2 was a big change (which is why they started calling it "Java 2"). There was also the "assert" addition in JDK 1.4 (though I'm not sure if that deserves a major number increment). They should have just upped it to 2.0 instead of 1.2. And now with all the new stuff, they could have incremented to 3.0 instead of looking like a bunch of (clueless) marketroids.
The explanation was hilarious:
"...because J2SE 5.0 is our biggest update to the platform since the original 1.0, it felt kind of stupid that we were still calling things 1.1, 1.2,..."
I don't see how 5.0 is the logical conclusion (ironic that they did this because the old way made them feel "kind of stupid").
For something like Linux, other distros are probably under pressure to "keep up" with Red Hat's version number (remember BeDope Linux?). Everyone just calls it Linux. For x86 CPUs it's also justifiable because most people think megahertz is a performance rating (and then ther are the Mac zealots who chant the Apple PR line "megahertz doesn't matter" immediately before suggesting doubling the PowerPC clockrate for comparison purposes).
For something like Java (or Solaris), there's no need to pull that kind of crap. Firstly, people will not think Java and.NET are the same thing so they won't think that.NET 2.0 is an upgrade of Java 1.5. Secondly, a version number is even worse as a performance rating than megahertz and I'm pretty sure that the target demographic isn't that stupid.
Correct me if I'm wrong, but isn't c#'s 'primitives' actual instances of objects (albeit they are passed by value)? If they're just a fancy Integer, why would it be quicker?
The very fact that they're passed by value speeds things up. C#, like Java, has two representations for each primitive. However, in C#, they go by the same name. They are automatically converted between 'int' and 'Integer' based on context (the conversion to/from the full object is called boxing/unboxing). Java has automatic boxing/unboxing now, but there are still two distinct and not-really-related types for each primitive. In C# it's more unified.
If the ArrayList<T> generic container uses arrays in its implementation, then ArrayList<int> will create a version of ArrayList<T> that has an 'int[]' (the unboxed integer). In Java, ArrayList<int> is syntatic sugar for ArrayList<Integer> and the internal representation will be 'Integer[]' (i.e. a array of pointers to integer objects). The Java version is a lot slower.
Note that this optimization doesn't necessarily depend on the existence of value types. A lot of the performance benefits you get from using value types can be achieved with a good JIT compiler and maybe some other form of compiler hinting.
The remoting optimization relies fundamentally on the immutability of an object.
Not exactly; value types are mutable types that can be marshaled by copying them. By using a value type, the programmer is explicitly telling the runtime that it's okay if an object gets out of sync once it's been passed to or returned from a function (for a remoted object, that it's okay if the local and remote copies differ). Since remote value types are mutable, I don't see what you mean by the above quoted statement.
Sorry, my mistake. The optimization depends fundamentally on copyability and immutability implies copyability. What I meant was that value types are essentially a compiler hint and don't help express program logic or design. Though compiler hints aren't necessarily bad things, value types significantly convolute the semantics when a good JIT compiler can figure most of this stuff out automatically.
For a mutable object, I think the to-copy-or-not-to-copy decision should be made on a case-by-case basis (instead of made at the class level). The class writer has less information about the appropriateness of a copy operation than the user of the class does.
A combination of escape analysis, immutability analysis/notation and use of the 'final' keyword gives the compiler enough information to perform all the optimization automatically without compromising uniformity.
Well, I've read in several places that best practice in Java is not to use final.
I've heard two arguments against using 'final':
Prematurely optimizing with 'final' can hurt your design. This doesn't seem to make sense when you think about the development process. Even if I mark a method final early on, if I see the need to override it, I'll take off the 'final'. Removing the 'final' keyword doesn't break anything.
There no performance benefit because the JIT compiler can infer this. This is true in a totally static environment. However, in the face of dynamic class loading it's a lot harder. You can't predict what types of classes you're going to be loading later on and so if the JIT does some optimistic optimization, it might have to redo a LOT of work.
As a side note, the C# way, which I prefer, is that virtual methods must be explicitly marked as such. The argument for this is that you're making lots of promises to subclassers when you create a virtual method and you should be forced to think about it.
If even one of the methods of a class is not final, the JIT will be unable to prove that the run time type is immutable. That's a pretty strong limit on the applicability of the approach you're talking about.
If you want to disallow derivation from your class, you can put the 'final' modifier before the 'class' keyword. You don't have to put it on every method. Also, I'm not saying that Java is ideal. I don't think it's that hard to infer immutability in most cases but I, for one, would not mind annotating my classes with the 'immutable' modifier (since it describes the design/logic of a program).
In addition, there are legitimate situations where it would be nice to have mutable types on the stack.
I don't see where it would be "nice" from a semantics point-of-view since you shouldn't be able to tell the difference. If it's for performance, then you don't have to worry. There are two optimizations here:
Making copies of immutable objects when convenient. This can be performed automatically by the compiler on immutable objects when it thinks that the cost of the copy will be offset by the quicker access (because you don't need to follow a pointer anymore).
What about security ? Don't you think the Java VM is able to control what the java bytecode is doing much more precisely than what the.NET VM can ? Isn't the Java bytecode much more structured than the.NET one ?
Wow...there seems to be some major confusion here. The CLR (.NET) bytecode is just fine. It's very similar to the JVM bytecode.
What might be causing confusion is that the CLR bytecode has some 'unsafe' instructions that allow a program to do, well, unsafe stuff. However, the instructions that allow this are NOT necessary to write programs. It is also very easy to tell your VM not to allow the execution of unsafe instructions.
The 'safe' subset of the CLR's instruction set is just as capable as the JVM's entire instruction set. The unsafe instructions were probably added to allow for efficient compilation of C++ code. They also let you do things in C# that you'd normally need to use JNI if you were using Java.
(And isn't that actually one of the reason java bytecode can be produced almost only from Java ?)
I don't think there's any instruction set that is so bizarre that only certain languages is capable of emitting it. The Mono C# compiler is written in C#. You could even emit unsafe CLR instructions from within C#.
Quite frankly, I am fairly dubious regarding the security of the bytecode produced by a C program:)
Security isn't enforced by the program that generates the bytecode (which would be a bad idea). It's enforced by the VM. I'm pretty sure that the MS VM, the Mono VM and the JVM are all written primarily in C or C++.
For example, being able to remote a value type (to another machine, for example) by copying it can in some situations be a big performance win over having to forward method calls on the object back to the machine where it lives.
The remoting optimization relies fundamentally on the immutability of an object. For example, copying immutable string objects is just fine. Structs, instead of corresponding directly to immutability, 'fake' it by enforcing value copying semantics instead, which goes against the way the rest of the language works.
Even from the performance perspective, structs are unnecessary. A combination of escape analysis, immutability analysis/notation and use of the 'final' keyword gives the compiler enough information to perform all the optimization automatically without compromising uniformity.
What's worse is that in C# they look just like regular classes, so it's harder to look at a chunk of code and figure out what it does.
Slashdot Mirror
Rob Pike has done some really cool stuff, but he's also kind of a weirdo. He doesn't believe in putting any "#include" directives in ".h" files. He says you should figure out what the dependencies are and put all the includes in your ".c" file.
Rob Pike's Notes on Programming in C (go to the bottom of the page).
How is it "just a compiler hack"? They had to modify the CLR instruction set to allow for type parameters. The underlying machine code is not the same. For reference types, the dynamic type check (which is really slow) is no longer neccessary. For value types, the code is definitely different since they'll deal directly with the values instead of dealing with them through boxes objects.
How can you claim not to care about performance at all? C# gets rid of the tedious casting and runs faster than Java. With value types, the performance difference even greater and allows programmers to use the collection classes in cases where they'd normally be forced to use arrays and do a lot of extra manual work. There is no downside. As a matter of fact, Java's downside is that you can't use generics wherever you want because the VM doesn't know about generic types and can't properly handle all the dynamic casts.
You seem to imply that the VM can be crashed by bad bytecode. This is not the case. Even though the VM has a simpler type system than the Java language, it is still type-safe. The main disadvantage to Java's approach is efficiency. In Java, the VM needs to check the type dynamically on every access. Also, the primitive types have to be boxed, creating a lot of overhead in both space and time.
The other disadvantage is the lack of orthogonality. Though type erasure is perfectly OK for languages that don't rely on the ability to perform unsafe casts, C# and Java programmers use do use some weak typing and therefore depend on the ability to perform type unsafe casts. The Java compiler issues warnings for cases where a type error will not be detected as early as it should be, limiting what you can do with unsafe casts. In C#, the extra type information lets you use unsafe casts to your heart's content.
And how many more job openings are there for Java than there are for PHP?
While 'ref' paramters are debatable, 'out' parameters are stupid. They should have created a way to return multiple values from a function. Allowing first class tuples would have been the correct way to do this (in most C-style languages, tuples are allowed as arguments to functions and disallowed everywhere else). Adding tuples would also have eliminated the need for the hacked up delegate functionality. Then again, Java doesn't have any equivalent functionality, so it could be seen as an advantage for C#.
Operator overloading is a good thing. It can be abused, but so can anything else. Removing operator overloading doesn't even come close to making it impossible to write obfuscated code. There are many situations where operator overloading makes things a lot simpler.
Properties are also good. Instead of identifying them through string matching ("get*", "set*"), language-level support for properties allows more accurate data type modelling. In the end, however, the CLR doesn't really have true support for properties. They implement them as methods (like Java, except at a lower level so most programmers don't have to care about it). This implementation mistake resulted in different opcodes for field access and property access, which means you cannot switch between fields and properties without changing the class's public interface (and breaking binary compatibility with client code). It's still better than what Java does...
Function pointers and anonymous functions. This has got to be the biggest improvement over Java. Unfortunately, class libraries were already designed before the anonymous function feature so they probably wont be designed to take advantage of it. Also, VB and C++ are probably holding things back because, as everyone knows, "language agnostic" is just a euphemism for "lowest common denominator".
You also forgot generator functions. They make it easier to write pull-style classes (a "pull" XML parser, for example). Though it isn't as powerful as full-blown continuation support, I think it'll still be useful for many coding tasks.
C# has more comprehensive generics support (aside from variance). Though both languages made the mistake of allowing arrays to be fully covariant (ArrayStoreException), Java got screwed when they decided not to maintain dynamic type information for generic type parameters. This limits the use of generics in often confusing ways. Type erasure isn't a problem in languages that have a good enough type system to avoid resorting to dynamic typing (like ML or Haskell). But C# and Java do not have good enough type systems and the C# people recognized that and chose to keep the dynamic type information around.
C# is better than Java in almost every way. Java has better enums and support for covariant and contravariant generic type parameters, but that's about it.
I wouldn't consider the Wikipedia to be a definitive source, especially for such an often-confused term. For all I know, you could have written that entry. Things I "learned" from that entry:
Look at entry on typed and untyped languages. It says that Perl is weakly typed. But you can't escape the Perl type system and cause a crash which means (by the other entry's definition) that it is strongly typed. So, apparently, some Wikipedia contributor doesn't agree that the two terms are equivalent.
Sure, Guy Steele is smart, but that doesn't mean he he never makes mistakes. At the time, the Java designers tried to eliminate unnecessary complexity, but it's hard to decide what "unnecessary" means without seeing the language in action. He now seems to think otherwise about generics and operator overloading (if, in fact, he originally thought they did not belong in Java), probably after seeing the collections and BigInteger in action.
You haven't made any specific arguments about how the features add unnecessary complexity and make the runtime less secure, but here's what people usually say:
What C# design mistakes make it worse than Java? Though I think value types were a mistake, Java doesn't really have a better way of handling them right now. I also mentioned that Java has better enums and variant typing. That's all I can think of (please respond if you can think of any more). Those advantages don't outweigh C#'s: function pointers, closures, generator functions, fast generics, isolatable runtime contexts, etc. C#'s improvements over Java probably won't make it worth your time to port your application, but there's no question that it is, overall, a better language.
Industry Support
Yes, Java has more industry support and more industry support is definitely better. However, there's a threshold after which you can safely use a language without worrying about tool support or the variety of available libraries. It's not a well-defined line, but C# is definitely going to cross it very soon. For many developers, the current level of support is probably good enough.
How does Java have better desktop platform penetration? It doesn't come with Windows either. Some OEMs might pre-install the JRE, but those OEMs are probably just as willing to pre-install the .Net runtime. While Longhorn wont be out for a while, it will be preinstalled by all the major desktop vendors when it does. It's not likely that Solaris (or any other OS that comes with Java pre-installed) will have a significant share of the market. It could happen, but it's a sensible decision to bet on Microsoft winning out again.
Companies that want uniform environments are willing to pre-install MS Office and Adobe Acrobat on all employee desktops. Why wouldn't they be willing to make the free .Net runtime part of the standard installation?
You are confusing typing strength with type-safety.
For example, you can have a crash-proof implementation of BF. Does that make BF type-safe? Yes; the type system is so pathetic that it's trivial to enforce type safety. Does it make BF strongly typed? No, because the type system doesn't do a good job of accurately describing the values you compute on. Tcl is also type-safe, but, again, the type system is weak (strings and lists are all you get).
Perl is often cited as a weakly typed language because strings and numbers are easily interchangeable. But this doesn't make Perl type-unsafe. Type-safety is enforced; it's just that there is a type called "scalar" that can handle both strings and numbers by design. Perl is weakly typed because many other languages make the distinction between strings and numbers and therefore more accurately describe values.
Type-safety means you cannot escape the type system. Strong typing means that your types are very precise descriptions of your values (relative to other languages).
Some examples:
Language | Safe | Typing StrengthTcl . .
C . . .
Old Java | Yes. | Medium. No parametric polymorphism.
New Java | Yes. | Strongish.
C++ . .
Haskell
Epigram
BTW, Python shouldn't really be considered strongly typed. The typing is weaker than Java's. Method invocations and field accesses are performed through string lookup.
The strongly typed version ensures that you're invoking the method you think you're invoking instead of invoking a method that simply has the same name. Python will not notice an error if GetElevatorButton() returns a BellyButton instead because method invocations are done by matching strings. Of course, the stronger typing doesn't really work well in a dynamically typed language. (Then again, dynamic typing is just a fad that will fade when people realize that what they really wanted was type inference).
C# is better than Java in almost every way:
You may hear about these "features" from pro-CLR people:
The only advantages the Java language has (that I can think of) are:
It's true that C# is mostly copied from Java. They didn't add any novel ideas. They just improved it incrementally (and screwed up a little too). But after everything is accounted for, it's clearly a better language. You can talk about "maturity" and "industry support" all you want, but some people are just happy to be using a superior language.
BTW, both "maturity" and "industry support" wont be problems for C#. It's not hard to design a mature language and set of class libraries when you have a working example to learn from. Also, Microsoft has mature designers working on the CLR and that counts for something too. As for "industry support", you have got to be joking. When they make the CLR come pre-installed on Longhorn, it will instantly become an industry standard. Even now it's available directly through Windows Update. The whole XAML/Avalon thing is not even ready yet but Amazon.com has already used it to build a prototype. It's depresing, but true: anything that comes out of Microsoft will have a completely unfair advantage over any competing products. Macromedia is next.
The faster your language, the less frequently you'll have to resort to C code. Statically typed languages are faster.
A lot of people have been saying that the interview disparages CVS and SVN without details. I didn't get that impression at all when reading the article.
I think the difference is that I've recently begun reading a lot about version control and have come across the issues he's mentioned. This is just a case of him assuming too much.
About the cvs-just-totally-sucks comments, I don't think they're way out of line. If you look at it from the perspective of a person who just started using CVS, then you may not think CVS sucks because you're comparing it to the no-version-control system. But if you look at it from the perspective of someone who is developing a version control system, CVS is really lacking.
Pipelines aren't the only way to pass data between separate programs. Sometimes the linear nature of pipelines makes some tasks less straightforward than it could be. The functional programming people have no problem combining the primitive operators to perform complicated operations (and you don't need glue code for that). The main motivation for relational databases was that they let you query your data in unanticipated ways.
I don't think pipelines are bad; they're really convenient for many tasks. But if the Monad guys are going through all the trouble of enforcing types on the data, they could take better advantage of the more powerful constructs that such typing allows.
With SQL, you don't have "everyting built into one program" (do you know what SQL is?). Individual queries aren't necessarily tied to each other. The extensibility comes from the fact that you can transform tables in arbitrary ways. You can write a "commandlet" to generate whatever kind of table you want.
I'm not suggesting that you'll need all the stuff a database gives you (keys, triggers, etc.). It's just that the RDBMS people have come up with good ways of dealing with tables and it would be a good idea to try and incorporate some of that.
It's great that they're trying to do something at a higher structural level. The Unix command line data structure is essentially just a sequence of '\n'-terminated lines. But while it looks like each filter command is doing its own thing (where, sort, group, etc.), they're really just doing the equivalent of an SQL 'SELECT'. I wonder why they are forcing the Unix-style pipeline syntax instead of a syntax that maps well to the relational model.
Anywhere. Just in case you really don't know how to look something up, here you go.
Look it up.
I really don't understand how you can argue against autoboxing. Can you honestly say that your first code snippet is not clearer than your second? Also, your example was unnecessarily long and just hurt your case. You could have written:
But that still has an unnecessary method call that autoboxing will eliminate.
The example doesn't work because the "++" operator only applies to storage elements (like variables and arrays). Ever tried doing "System.currentTimeMillis()++"? Java programmers are used to this because the collection APIs were never totally transparent (i.e. they never were as concise as array access); the Java language (like some others) doesn't support it because, unlike values, storage elements are not first-class.
You don't have to "go back to casting Integers again." Going back to casting integers gives you nothing, because java.lang.Integer objects are immutable, just like int values. If all you have is an Enumeration or an Iterator, then you can't swap out elements of a Collection object. If you have an array, then I doubt you'd be taking advantage of autoboxing anyway. If you were using an ArrayList then compare the autoboxed way:
Even on one line, it's less readable:
Here, autoboxing can eliminate two conversions for you (one on the get and one on the set. I just can't understand why someone would want to explicitly write out the mechanical conversions that a compiler can perform for you (with 100% accuracy).
If object-pooling is a prerequisite for a good program, then the runtime system isn't doing it's job. It is a pain to perform object pooling and you have to design your objects differently if you want to allow them to be pooled.
It would probably be a better idea to attach attributes to classes to provide hints about how they're going to be used. That way you don't have to actually change the way your program works to reap the benefits of pooled objects. Make the VM do it for you.
A lot of the time, a generational garbage collector can handle the deallocation of many short lived objects efficiently. In the canonical copying collector implementation (a generational GC is a copying collector) allocation is extremely cheap too (just incrementing a global variable) and has a good chance of being much faster than maintaining a weakly-referenced free list object pool.
Java is not supposed to hide pointers from the developer. Haskell accomplishes such a thing, but it also doesn't allow side-effects. If you want to allow side-effects (i.e. mutable shared variables), hiding pointers is much more difficult.
You may decide to call them "references" instead of "pointers" but they're essentially the same thing. It's just that Java doesn't let you perform arithmetic on them.
Referential equality can be useful and so there's reason to give a programmer access to it, but value-based equality comparision is the common case and probably should have been assigned to the '==' operator. One reason they may not have done so is to avoid hidden complexity. In C, for example, you can look at a chunk of code and get a good sense of what's going on. In C++ (which is an extreme case) a chunk of code that looks simple might be doing a bunch of other crazy things using operator overloading and automatically-invoked destructors.
As for your comment about this "making no sense"... It makes sense when you realize the '==' compares the values of variables and does not go the extra mile to dereference pointers and invoke comparison functions. While it may have been a good idea to do all that extra stuff, the current semantics are not confusing.
It sort of is a patent on kernels (which perform administrative functions for non-priveleged processes).
I think he meant to say that that Internet traffic pays 10 cents per megabyte of him.
I think that was the original story, but that doesn't make any sense either. The language has changed, but they kept calling it Java 2.
Originally, they seemed to be actively avoiding increasing the the major version number. JDK 1.2 was a big change (which is why they started calling it "Java 2"). There was also the "assert" addition in JDK 1.4 (though I'm not sure if that deserves a major number increment). They should have just upped it to 2.0 instead of 1.2. And now with all the new stuff, they could have incremented to 3.0 instead of looking like a bunch of (clueless) marketroids.
The explanation was hilarious:
I don't see how 5.0 is the logical conclusion (ironic that they did this because the old way made them feel "kind of stupid").
For something like Linux, other distros are probably under pressure to "keep up" with Red Hat's version number (remember BeDope Linux?). Everyone just calls it Linux. For x86 CPUs it's also justifiable because most people think megahertz is a performance rating (and then ther are the Mac zealots who chant the Apple PR line "megahertz doesn't matter" immediately before suggesting doubling the PowerPC clockrate for comparison purposes).
For something like Java (or Solaris), there's no need to pull that kind of crap. Firstly, people will not think Java and .NET are the same thing so they won't think that .NET 2.0 is an upgrade of Java 1.5. Secondly, a version number is even worse as a performance rating than megahertz and I'm pretty sure that the target demographic isn't that stupid.
The very fact that they're passed by value speeds things up. C#, like Java, has two representations for each primitive. However, in C#, they go by the same name. They are automatically converted between 'int' and 'Integer' based on context (the conversion to/from the full object is called boxing/unboxing). Java has automatic boxing/unboxing now, but there are still two distinct and not-really-related types for each primitive. In C# it's more unified.
If the ArrayList<T> generic container uses arrays in its implementation, then ArrayList<int> will create a version of ArrayList<T> that has an 'int[]' (the unboxed integer). In Java, ArrayList<int> is syntatic sugar for ArrayList<Integer> and the internal representation will be 'Integer[]' (i.e. a array of pointers to integer objects). The Java version is a lot slower.
Note that this optimization doesn't necessarily depend on the existence of value types. A lot of the performance benefits you get from using value types can be achieved with a good JIT compiler and maybe some other form of compiler hinting.
Sorry, my mistake. The optimization depends fundamentally on copyability and immutability implies copyability. What I meant was that value types are essentially a compiler hint and don't help express program logic or design. Though compiler hints aren't necessarily bad things, value types significantly convolute the semantics when a good JIT compiler can figure most of this stuff out automatically.
For a mutable object, I think the to-copy-or-not-to-copy decision should be made on a case-by-case basis (instead of made at the class level). The class writer has less information about the appropriateness of a copy operation than the user of the class does.
I've heard two arguments against using 'final':
As a side note, the C# way, which I prefer, is that virtual methods must be explicitly marked as such. The argument for this is that you're making lots of promises to subclassers when you create a virtual method and you should be forced to think about it.
If you want to disallow derivation from your class, you can put the 'final' modifier before the 'class' keyword. You don't have to put it on every method. Also, I'm not saying that Java is ideal. I don't think it's that hard to infer immutability in most cases but I, for one, would not mind annotating my classes with the 'immutable' modifier (since it describes the design/logic of a program).
I don't see where it would be "nice" from a semantics point-of-view since you shouldn't be able to tell the difference. If it's for performance, then you don't have to worry. There are two optimizations here:
Wow...there seems to be some major confusion here. The CLR (.NET) bytecode is just fine. It's very similar to the JVM bytecode.
What might be causing confusion is that the CLR bytecode has some 'unsafe' instructions that allow a program to do, well, unsafe stuff. However, the instructions that allow this are NOT necessary to write programs. It is also very easy to tell your VM not to allow the execution of unsafe instructions.
The 'safe' subset of the CLR's instruction set is just as capable as the JVM's entire instruction set. The unsafe instructions were probably added to allow for efficient compilation of C++ code. They also let you do things in C# that you'd normally need to use JNI if you were using Java.
I don't think there's any instruction set that is so bizarre that only certain languages is capable of emitting it. The Mono C# compiler is written in C#. You could even emit unsafe CLR instructions from within C#.
Security isn't enforced by the program that generates the bytecode (which would be a bad idea). It's enforced by the VM. I'm pretty sure that the MS VM, the Mono VM and the JVM are all written primarily in C or C++.
The remoting optimization relies fundamentally on the immutability of an object. For example, copying immutable string objects is just fine. Structs, instead of corresponding directly to immutability, 'fake' it by enforcing value copying semantics instead, which goes against the way the rest of the language works.
Even from the performance perspective, structs are unnecessary. A combination of escape analysis, immutability analysis/notation and use of the 'final' keyword gives the compiler enough information to perform all the optimization automatically without compromising uniformity.
What's worse is that in C# they look just like regular classes, so it's harder to look at a chunk of code and figure out what it does.