In putting my C# knowledge into practice, I've found that most of my linguistic gripes against learning it have been solved in .NET 3.0 / 3.5, and making portable code that works under Winows and Unix is just as easy as expected: in fact I test everything against the compilers from Microsoft and Mono. I've not had any troubles, and I am using like last years Mono version. Although, I must admit that I think of Monos setup as the "Novell implementation" and .NET as Microsoft's >_>. The portability of C# is every bit as good as Java and dynamic languages. In fact, if it wasn't for the Mobile version (Java ME), I would say C# is more portable than Java these days.
C# already have features that are expected in Java 7 and C++0x, but everyone will be damned if they will get to use any time soon. To top it off given the blasted prevalence of Windows machines, just about everyone will have a liveable version of the .NET runtime that you can program to in a pinch. Between actually using the computer, newer Windows versions, just about all of them will have a modern version. Plus several popular unix applications (and parts of the Gnome software stack) are written in C#, so the same goes for many Linux distributions. Alas the same can't be said of getting various C/C++ libraries compiled....
C# already have features that are expected in Java 7 and C++0x, but everyone will be damned if they will get to use any time soon. To top it off given the blasted prevalence of Windows machines, just about everyone will have a liveable version of the .NET runtime that you can program to in a pinch. Between actually using the computer, newer Windows versions, just about all of them will have a modern version. Plus several popular unix applications (and parts of the Gnome software stack) are written in C#, so the same goes for many Linux distributions. Alas the same can't be said of getting various C/C++ libraries compiled....
Compared to Java, C# is a mixture of what Java should have evolved into as a business language, and a bit of C++ style. C# also goes to lengths to make somethings more explicit, in a way that can only be viewed as Java or COBOL inspired. I'll try not to think about which. I think of professional Java and C# programming as our generations version of Common Business Oriented Language without the associated stigmatism.
The concept of "C++" style in C# however, is something of a moot point when we talk about Java too. Here's a short comparison to explain:
The concept of "C++" style in C# however, is something of a moot point when we talk about Java too. Here's a short comparison to explain:
// C++ class
class Name : public OtherClass, public SomeInterface, public OtherInterface { /* contents */ };
// Java class
public class Name extends OtherClass implements SomeInterface, OtherInterface { /* contents */ }
// C# class
public class Name : OtherClass, SomeInterface, OtherInterface { /* contents */ }
It should be noted in the above example, that C++ trades the ease of control over class visibility for fine grained control over inheritance. AFAIK, Java/C# has no concept of private / protected / virtual {x} inheritance. Likewise C++ is multiple inheritance, while Java and C# are single inheritance. This all leads to a more verbose class syntax in C++.
Now this one, is where you know how Java is run ;)
// C++ foreach, STL based std::for_each(seq.end(), seq.begin(), func); // C++ foreach, common technique for (ClassName::iterator it = seq.begin(); it != seq.end(); ++it) /* contents */elementtype // C++ foreach, to be added in the *future* standard (see below for disclaimer) for (auto elem : seq) /* contents */ // Java foreach, <= 5.0 for (Iterator it = seq.iterator(); it.hasNext();) /* contents */ // Java foreach, >= 5.0 for (ElementType elem : seq) /* contents */ // C# foreach for (var elem in seq) /* contents */
As you noticed, there's three different examples for C++. The first uses the for_each algorithm and leads to rather simple code; the second is the most common way; the third is being added in C++0x and I haven't bothered to read the details of it, since the version of GCC here doesn't support it.
C++ again gives very fine grained control here, the for_each algorithm and iterator methods are extremely useful once you learn how C++ really works. If you don't, than please don't program seriously in C++! The C++0x syntax is +/- adding a foreach keyword, exactly what you would expect a foreach statement to look like, if C++ had one. Some things like Boost / Qt add a foreach macro that is mostly the same, but with a comma.
Java enhanced the for statement back in 2004, when Java 5 added a foreach like construct. Java hasn't changed much since then. When you compare the keyword happy syntax of Java to the punctuation happy syntax of C++, it becomes clear that Java's developers had decided doing it C++ style was worth more than adding any new keywords, like foreach and in. Guess they didn't think to steal perls foreach statement for ideas on how to naturally side step it.
C# on the other hand, uses the kind of foreach statement that a Java programmer would have 'expected', one that actually blends in with the language rather than sticking out like a haemorrhoid. I might take a moment to note, that javac can be so damn slow compared to C++/C# compilers, that the lack of type inference in Java is probably a good thing!
In terms of syntax, Java is like C among it's OO peers: it's about as small and minimalist a syntax as you can get without being useless. I wish I could say the same about Java in general. Some interesting parts of C#, include properties and the out and ref keywords.
Here's a comparison of properties in Java and C#:
class Java {
private PropType prop;
public PropType getProp() {
return this.prop;
}
public void setProp(PropType prop) {
this.prop = prop;
}
public void sample() {
PropType old = getProp();
setProp(new PropType());
}
}
class CSharp {
public PropType prop { get; set; }
public void sample() {
PropType old = prop;
prop = new PropType();
}
}
C# has a very sexy way of doing getter/setter like methods for properties. Personally I prefer the more C++ like style of just having a public field, unless you need to hook it (with a getter) or use a private setter. I like how C# can make it look like a field, when it's actually a getter/setter method like construct. That means you don't have to remember which fields are accessed directly and which need member function calls when writing code. Java convention is getter/setter bloat; C# convention is to use properties for anything non-private. I hope C# 5.0 or 6.0 will replace { get; set; } with just add a property keyword alongside the access modifier.
C++ is just as lame as Java in doing getter/setter methods, except you can (ab)use the pre processor for creating such basic accessors as the above, as well as any similar methods you need but don't want to copy/paste+edit around. Java and C# always make you write your own, unless they are the basic kind. Tricks involving Java annotations and subclassing can kiss my hairy ass. It's also worth noting that some Java projects can use an insane amount of getter/setter code. Come on guys. Using an external tool is not the right solution.
When we compare the age of these languages: C++ => 27 years old; Java => 15 years old; C# => 9 years old. It becomes obvious that C# is the only one that doesn't suck at the concept of "Properties" and getter/setters in general. Perl made love constructs that respect the programmers time more than the compiler writers: you should too.
To anyone who wants to dare note that Java IDEs can often auto-generate getter/setters for you, and dares to call that better than language level support, I can only say this: you're a fucking moron. Go look up an Abraham Lincoln quote about silence. Now if someone wants to be constructive and create another Java example equal to the C# example in the above listing, I'll be happy to add it: rules must be shorter than existing Java example, uses: no subclassing, no beans, no external programs or libraries. Be sure to note what Java version it requies. Cheers.
The ref and out keywords in C#, are actually kind of oddities, if you come from another main stream language. In C it is not uncommon to pass a variable (perhaps more correctly a block of memory, if you think about it) to a function: and have the function modify the variables value instead of returning it.
In this case, pData is a pointer to some data type, likely a structure, to be filled out by the do_something function. The point is, it's intended as a mutable parameter. In C/C++, it's trivial to do this for any data type because of how pointers work. Java passes by value just like C and C++ do: you can modify non-primitive types because a reference is used, not the 'actual' value. Making it more like a reference than a value type, in CS speak. C# does the same thing.
Now a little fun with the self documenting ref keyword in C#:
The out/ref keywords are similar, the difference has to do with assignment; RTFM. The important thing is that it is a compiler error to pass the data without the ref/out keywords at the call site. I'm both enough of a Python and C++ programmer to enjoy that. This explicitness helps catch a few typos, and helps document that it's meant to be passed by reference, not value. That's good because a lot of programmers suck at documentation and some also blow at naming parameters. I think the contractual post/pre conditions in Spec# are a good thing: by removing writing the handlers form the programmer, and not having to make the programmer rewrite the flibbin' things in prose somewhere in the documentation. Not to mention the classic "Oops" just waiting to happen in less DbC oriented syntaxes. Hate to say it but the ref/out keywords presence in vanilla C# are likely due to Win32 API documentation conventions \o/.
Where C# really rocks is in the CLI. Java has something good going for it, over the past 15 years the Java Virtual Machine (JVM) has been heavily tuned for performance, Mono and Hotspot also present quite an interesting set of options (that .NET lacks afaik). I assume that Microsoft's implementation has also been battle tested for performance as well.
The thing of that is, the JVM was originally designed to run JAVA, first and foremost at the end of the day, that is what it had to do. The Common Language stuff on the other hand was intended to run several different languages. Although admittedly languages native to CLI tend to be similar, but so are most languages in general. The interoperability between CLI languages is wonderful, and at least in native .NET languages tends to be "Natural" enough. By contrast things crammed into JVM bytecode tend to become rather ugly IMHO, when it comes to interfacing with Java. I'm not sure if that's due to the JVM or the language implementations I've seen, the changes coming in Java 7 make me guess it's the former. The CLI is likely the next best thing to making a group of languages compile down to native code (for performance) and share some form of common ABI. Fat chance that will ever happen again. I'm sure I want to ponder about VMS, but the whole CLI thing tends to work quite nice in practice The performance cost is worth it for the reduction in headaches.
I'm sure that in terms of performance that Java mops the floor with Mono in some areas, because of how much hacking has gone into it making it a cash cow. That the C# compilers seems to run ring around the defacto standard Java compiler, is what really catches my interest performance wise. Using the mono 2.4.4 and Java 1.6.0_18 compilers, on my very modest system mcs processes a minimal program about 30% faster than javac. In real opeartion it tends to kick ass. When you consider that each compiler is also implemented in the target language, Java really gets blown away. O.K. maybe I care more about compile times than many people, it's the virtue of using an older machine :-P. Combine that with how many slow, buggy, monstrosities have been written in Java—I'll salute C# first. Another plus is less "Our tools demand you do it THIS WAY" than what Sun threw at everyone. Piss on javac and company.
What has hurt C# in my opinion is the Microsoft connection. The thing with Novell doesn't help either. That Java is not exactly an insanely popular language among hackers, so much as enterprises, is another. The things that have hurt Java, being so closed and being academics choice for stupifying students.
What's the upside to using Java over C#? Easier access to Java libraries, (J2ME) mobile phones, and more finger exercise from all that needless typing! Beyond that it's essentially a win, win in favour of C#.
C++ is just as lame as Java in doing getter/setter methods, except you can (ab)use the pre processor for creating such basic accessors as the above, as well as any similar methods you need but don't want to copy/paste+edit around. Java and C# always make you write your own, unless they are the basic kind. Tricks involving Java annotations and subclassing can kiss my hairy ass. It's also worth noting that some Java projects can use an insane amount of getter/setter code. Come on guys. Using an external tool is not the right solution.
When we compare the age of these languages: C++ => 27 years old; Java => 15 years old; C# => 9 years old. It becomes obvious that C# is the only one that doesn't suck at the concept of "Properties" and getter/setters in general. Perl made love constructs that respect the programmers time more than the compiler writers: you should too.
To anyone who wants to dare note that Java IDEs can often auto-generate getter/setters for you, and dares to call that better than language level support, I can only say this: you're a fucking moron. Go look up an Abraham Lincoln quote about silence. Now if someone wants to be constructive and create another Java example equal to the C# example in the above listing, I'll be happy to add it: rules must be shorter than existing Java example, uses: no subclassing, no beans, no external programs or libraries. Be sure to note what Java version it requies. Cheers.
The ref and out keywords in C#, are actually kind of oddities, if you come from another main stream language. In C it is not uncommon to pass a variable (perhaps more correctly a block of memory, if you think about it) to a function: and have the function modify the variables value instead of returning it.
/* Common if not enjoyable idiom in C */
if (!do_something("some", "params", pData) {
/* handle failure */
}
/* use pData */
In this case, pData is a pointer to some data type, likely a structure, to be filled out by the do_something function. The point is, it's intended as a mutable parameter. In C/C++, it's trivial to do this for any data type because of how pointers work. Java passes by value just like C and C++ do: you can modify non-primitive types because a reference is used, not the 'actual' value. Making it more like a reference than a value type, in CS speak. C# does the same thing.
// Java pass by value
public void test() {
int x=10;
Java r = new Java();
r.setProp(PropType.OldValue);
mutate(x, r);
// x = 10; r.prop = PropType.NewValue
}
public void mutate(int x, Java r) {
x = 20;
r.setProp(PropType.NewValue;
}
Now a little fun with the self documenting ref keyword in C#:
public void test() {
int x = 10;
var r = new CSharp;
r.prop = PropType.OldValue;
mutate(ref x, r);
// x = 20; r = PropType.NewValue
}
public void mutate(ref int x, CSharp r) {
x = 20;
r.prop = PropType.NewValue;
}
The out/ref keywords are similar, the difference has to do with assignment; RTFM. The important thing is that it is a compiler error to pass the data without the ref/out keywords at the call site. I'm both enough of a Python and C++ programmer to enjoy that. This explicitness helps catch a few typos, and helps document that it's meant to be passed by reference, not value. That's good because a lot of programmers suck at documentation and some also blow at naming parameters. I think the contractual post/pre conditions in Spec# are a good thing: by removing writing the handlers form the programmer, and not having to make the programmer rewrite the flibbin' things in prose somewhere in the documentation. Not to mention the classic "Oops" just waiting to happen in less DbC oriented syntaxes. Hate to say it but the ref/out keywords presence in vanilla C# are likely due to Win32 API documentation conventions \o/.
Where C# really rocks is in the CLI. Java has something good going for it, over the past 15 years the Java Virtual Machine (JVM) has been heavily tuned for performance, Mono and Hotspot also present quite an interesting set of options (that .NET lacks afaik). I assume that Microsoft's implementation has also been battle tested for performance as well.
The thing of that is, the JVM was originally designed to run JAVA, first and foremost at the end of the day, that is what it had to do. The Common Language stuff on the other hand was intended to run several different languages. Although admittedly languages native to CLI tend to be similar, but so are most languages in general. The interoperability between CLI languages is wonderful, and at least in native .NET languages tends to be "Natural" enough. By contrast things crammed into JVM bytecode tend to become rather ugly IMHO, when it comes to interfacing with Java. I'm not sure if that's due to the JVM or the language implementations I've seen, the changes coming in Java 7 make me guess it's the former. The CLI is likely the next best thing to making a group of languages compile down to native code (for performance) and share some form of common ABI. Fat chance that will ever happen again. I'm sure I want to ponder about VMS, but the whole CLI thing tends to work quite nice in practice The performance cost is worth it for the reduction in headaches.
I'm sure that in terms of performance that Java mops the floor with Mono in some areas, because of how much hacking has gone into it making it a cash cow. That the C# compilers seems to run ring around the defacto standard Java compiler, is what really catches my interest performance wise. Using the mono 2.4.4 and Java 1.6.0_18 compilers, on my very modest system mcs processes a minimal program about 30% faster than javac. In real opeartion it tends to kick ass. When you consider that each compiler is also implemented in the target language, Java really gets blown away. O.K. maybe I care more about compile times than many people, it's the virtue of using an older machine :-P. Combine that with how many slow, buggy, monstrosities have been written in Java—I'll salute C# first. Another plus is less "Our tools demand you do it THIS WAY" than what Sun threw at everyone. Piss on javac and company.
What has hurt C# in my opinion is the Microsoft connection. The thing with Novell doesn't help either. That Java is not exactly an insanely popular language among hackers, so much as enterprises, is another. The things that have hurt Java, being so closed and being academics choice for stupifying students.
What's the upside to using Java over C#? Easier access to Java libraries, (J2ME) mobile phones, and more finger exercise from all that needless typing! Beyond that it's essentially a win, win in favour of C#.
No comments:
Post a Comment