The fact that Java maintains its portability even though it specifies bit widths is due to the JRE/JVM which can handle 32 bit ints on 16 bit architectures. All this means is that the compiled code will not run on a system C# was not compiled for. Duh.
I've scanned and lightly perused the C# introduction which Microsoft published. Having heard that it compares to Java, I wanted to compare it for myself. Here I report to you all my observations.
Platform specificity Not too ironically, Microsoft published this "introduction" in an MS-Word/DOC encoded format, compressed by a DOS-based self-extracting tool. Also, not too ironically, the introduction states early on that C# is a Microsoft platform specific language: Every object compiles into a COM object. (No mention of D-Com/Active X is made.) Ultimately, only systems capable of running COM will be capable of supporting a program compiled via C#.
The portability concerns grow from there. For instance, the introduction specifies bit-lengths for various pre-defined types. The introduction also notes that even constants and literals are compiled as Class-instances. Thus, you could write the code "6.ToString();". And you can't rely on a pre-processor for constant defining -- apparently, you must use package and class constants (and "Attributes" -- see below). In another example of platform-specific code generation, user-defined functions and methods are allowed to be declared with variable-length arguments. Are these arguments passed in Pascal or C order? It's a complete mystery to me, since Windows has historically been first-to-last argument passing, and variable-length functions were exceptions to this rule. What will happen to this code on register-heavy stack frames? Then there are the "unclean" code sections in which pieces of code can be marked as such and written, for instance, in an entirely different language, such as C or C++, or using C pointers and assembly to defeat (or rather, embrace and extend) the compiler's bytecode verifier! In sum, the language reinforces many techniques and programming styles which will be highly platform- and architecture-specific. Developers will probably struggle for years developing coding techniques which avoid these platform dependencies.
Syntax similarities. C# and Java appear to be nearly identical from a syntax standpoint. Several outstanding counterexamples include: C#'s "using" declaration to pull in classes instead of Java's "import"; C# includes new keywords such as "event" to explicitly specify the need for a delegation method; C# incorporates "rectangular arrays" which look like Pascal arrays, instead of the C/C++/Java "array of arrays" notation; an "API" to allow the inlining of other language code, such as C++ and C; and C# has operator overloading much like C++ does. Personally, I frown upon the "rectangular" array notation, as that complicates arrays and litters the language with superflous features; otoh, presumably, these arrays are much faster. I'm also upset that C# follows Java "lead" in removing automatic type conversion from integer to boolean and vice-versa; but I recognize this brings cheers to many C programmers. Finally, operator overloading, the eye-candy of all programming language constructs, was "retained" from C++. If for no other reason, I will not use C# because it allows programmers to create code more confusing than macro assembly during its prime.
Unincorporated Java features. The introduction did not mention threading at all, or security in specific detail. The lack of threading won't be missed by many, but it certainly will be a loss; threading will have to be handled through the OS and presumably through a class interface, which will again, tie the language to the MS platform (for a while). And while the introduciton briefly mentions a bytecode verifier in the compiler and execution stages, it's hard to see how this will work when methods can have variable length arguments. It's also hard to see how "unsafe" code will be safer simply because the code is "marked" unsafe. Buffer overflows and honest-to-goodness bugs will plague C# programmers just as they did C programmers.
Miscellaneous Differences. C# requires the user to explicitly pass-by-reference, whereas in Java, all Objects are passed by reference. Programmers in Java might be confused for a while at the notion that a literal like '6' will be passed as a copied Object unless otherwise specified as a reference. The "event" keyword might screw up a few unsuspecting programmers wanting to create their own "event" enum or variable or class. I did not see explicit references to the a Java-like String class with "+" style concatenation; instead, a method "WriteLine" will look somewhat like fprintf, but apparently without any type checking whatsoever. The keyword "readonly" replaces "const". Variables cannot be used until assigned to (who cares if they're automatically initialized to 0??). The concept of "Attributes" seems to blend C++ templates, C's include and typedef, and Java's RTI class methods.
Summary. This language improves on C, somewhat, by creating a simple to use Object oriented language based familiar to C programmers. But this language is more like a somewhat scaled-down C++, with single inheritance and no direct support for templates and simplified pointer and reference support. And therein lies the problem: it fundamentally does not really improve on C++, but makes the language appear more Java like. And while it may seem like Java from afar, it does not incorporate Java's main selling points: cross-platform, bytecode verifcation for security, multi-threading, and true OO inheritance (as opposed to COM "inheritance").
Still, I would strongly consider writing my first ASP COM object in C# rather than C++, and likely many other people will as well. I mean, if you're going to be against cross platform, open architectures, why use a language anyone else can use? Use C# and remain a dedicated MS shop forever.
Slashdot Mirror
The fact that Java maintains its portability even though it specifies bit widths is due to the JRE/JVM which can handle 32 bit ints on 16 bit architectures. All this means is that the compiled code will not run on a system C# was not compiled for. Duh.
Platform specificity Not too ironically, Microsoft published this "introduction" in an MS-Word/DOC encoded format, compressed by a DOS-based self-extracting tool. Also, not too ironically, the introduction states early on that C# is a Microsoft platform specific language: Every object compiles into a COM object. (No mention of D-Com/Active X is made.) Ultimately, only systems capable of running COM will be capable of supporting a program compiled via C#.
The portability concerns grow from there. For instance, the introduction specifies bit-lengths for various pre-defined types. The introduction also notes that even constants and literals are compiled as Class-instances. Thus, you could write the code "6.ToString();". And you can't rely on a pre-processor for constant defining -- apparently, you must use package and class constants (and "Attributes" -- see below). In another example of platform-specific code generation, user-defined functions and methods are allowed to be declared with variable-length arguments. Are these arguments passed in Pascal or C order? It's a complete mystery to me, since Windows has historically been first-to-last argument passing, and variable-length functions were exceptions to this rule. What will happen to this code on register-heavy stack frames? Then there are the "unclean" code sections in which pieces of code can be marked as such and written, for instance, in an entirely different language, such as C or C++, or using C pointers and assembly to defeat (or rather, embrace and extend) the compiler's bytecode verifier! In sum, the language reinforces many techniques and programming styles which will be highly platform- and architecture-specific. Developers will probably struggle for years developing coding techniques which avoid these platform dependencies.
Syntax similarities. C# and Java appear to be nearly identical from a syntax standpoint. Several outstanding counterexamples include: C#'s "using" declaration to pull in classes instead of Java's "import"; C# includes new keywords such as "event" to explicitly specify the need for a delegation method; C# incorporates "rectangular arrays" which look like Pascal arrays, instead of the C/C++/Java "array of arrays" notation; an "API" to allow the inlining of other language code, such as C++ and C; and C# has operator overloading much like C++ does. Personally, I frown upon the "rectangular" array notation, as that complicates arrays and litters the language with superflous features; otoh, presumably, these arrays are much faster. I'm also upset that C# follows Java "lead" in removing automatic type conversion from integer to boolean and vice-versa; but I recognize this brings cheers to many C programmers. Finally, operator overloading, the eye-candy of all programming language constructs, was "retained" from C++. If for no other reason, I will not use C# because it allows programmers to create code more confusing than macro assembly during its prime.
Unincorporated Java features. The introduction did not mention threading at all, or security in specific detail. The lack of threading won't be missed by many, but it certainly will be a loss; threading will have to be handled through the OS and presumably through a class interface, which will again, tie the language to the MS platform (for a while). And while the introduciton briefly mentions a bytecode verifier in the compiler and execution stages, it's hard to see how this will work when methods can have variable length arguments. It's also hard to see how "unsafe" code will be safer simply because the code is "marked" unsafe. Buffer overflows and honest-to-goodness bugs will plague C# programmers just as they did C programmers.
Miscellaneous Differences. C# requires the user to explicitly pass-by-reference, whereas in Java, all Objects are passed by reference. Programmers in Java might be confused for a while at the notion that a literal like '6' will be passed as a copied Object unless otherwise specified as a reference. The "event" keyword might screw up a few unsuspecting programmers wanting to create their own "event" enum or variable or class. I did not see explicit references to the a Java-like String class with "+" style concatenation; instead, a method "WriteLine" will look somewhat like fprintf, but apparently without any type checking whatsoever. The keyword "readonly" replaces "const". Variables cannot be used until assigned to (who cares if they're automatically initialized to 0??). The concept of "Attributes" seems to blend C++ templates, C's include and typedef, and Java's RTI class methods.
Summary. This language improves on C, somewhat, by creating a simple to use Object oriented language based familiar to C programmers. But this language is more like a somewhat scaled-down C++, with single inheritance and no direct support for templates and simplified pointer and reference support. And therein lies the problem: it fundamentally does not really improve on C++, but makes the language appear more Java like. And while it may seem like Java from afar, it does not incorporate Java's main selling points: cross-platform, bytecode verifcation for security, multi-threading, and true OO inheritance (as opposed to COM "inheritance").
Still, I would strongly consider writing my first ASP COM object in C# rather than C++, and likely many other people will as well. I mean, if you're going to be against cross platform, open architectures, why use a language anyone else can use? Use C# and remain a dedicated MS shop forever.
I'll try to read it in the next day or two and give my opinion on what I see.