I code in java on the side for some small business apps. I've also coded in C# and have used all of the MS Visual Stuido nonsense. Both languages are at a level that you can do just about anything with one that you can do with the other. So the deciding factors come down to really which is a better platform to develop on and cross platform compatibility (in some cases the latter isn't an issue, but it is for me). As far as IDE's go,I don't get what people like about Visual Studio, especially VS.net. I enjo
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.
For covariant and contravariant exist several definitons depending on context (inheritance versus template parameters, e.g.)
Suppose you have a class like this:
class A {
A method() { return new A() } }
And another class like this: class B extends A {
B method() { return new B() } }
This construct is called covariant. The class B is ingeriting from A, while the method method() is overwritten in B. Not only is the mthod redefined but also the return value is. As it is redefined to the taype of the class, this is called covariant.
If the method in A would return a B and the method in B an A, it would be called contravariant.
For template parameters there are similar definitions, but they are a bit more complex.
>Can somebody explain what you mean by the covariant and contravariant things.
In an OO language with objects and types we may say that a type, ST is a subtype of T. The meaning of this is that an object of type ST can be used where an object of type T is expected.
Objects of type ST can have more operations (functions) than objects of type T, but it must have the same operations as objects of type T. These operations must have the same number of arguments and results as operations in T. But the arguments
Out parameters are kind of neccesary if you have ref parameters. They are basically ref parameters that MUST return a value and because C# requires all variables be initalized, if you have ref, you must have out and you must force all ref params to be initalized before being passed in.
Out parameters are mainly for use with API calls that return strings and such in reference paramters.
As far as I know, nowhere does the base class library use out paramters (I am sure there is somewhere, but it is probably o
"Out" parameters are used to return more than one value. But "out" parameters are the wrong way to accomplish that. They are a holdover from the old C technique for faking multiple return values.
I don't know about the C# implementation, but in general, it is possible to define out parameters so that they are different from return values. Namely according to the time when they are modified. Look at the following code in an hypothetical, C-like language (and to better make my point, it contains the named return value extension which for some time was part of gcc):
int global;
void test() {
print(global); }
int with_return() return result {
test();
result = 5;
test(); }
I am aware of this behavior, but it's not usually what the programmer requires. I'm betting that 99% of the time 'out' is used, the programmer doesn't rely on this weird behavior. All he wants is multiple return values. The other 1% of the time probably consists of things you shouldn't be doing anyway:)
The advantage of tuples is that they make things more general. C, Java and C# do have tuples. It's just that they're only allowed as arguments to functions. This limitation makes it really difficu
You are 100% correct. There are many C functions that return a string by returning the string length (or a negative return code) and by putting the string into a preallocated buffer passed in as an "out" paramter.
From my understanding, the out keyword in.NET is primarily to ease the use of these functions.
Just because operator overloading can be used for evil is no reason to throw the baby out with the bathwater.
Java lacks a Currency class, so I wrote a Money class some time ago that I use for common financial calculations, and it takes care of the pesky problem (and newbie mistake) of using floating point types for money.
BUT, in Java, you have to have add(), sub(), mult(), and div() methods. Reading RPN style caclulations consisting of sequenced and nested method calls instead of algebraic operators is painful. Operator overloading is wonderful in those cases.
Operator overloading certainly can be evil: What does it mean to increment an Employee? Do I really want to know? But for new types that you can actually do algebra with, it is quite helpful.
And there are other cases.
In my C++ days I wrote a FileHash class that kept an index of offsets to the start of each text line in a text file. Then I overloaded the array subscript operator so that a text file could used like an array of char pointers (or a String class if you liked). That was a perfectly good use of overloading.
Moreover I think overloading the array subscript on ordered collections also makes perfect sense.
I often wish Java had this feature. I agree with every simplifying choice they made except this one.
BigDecimal doesn't a Currency class make. I'm talking about something that will do currency exchange and financial calculations. Mine uses BigDecimal inside.
But even if you just handle one currency and can thus use BigDecimal directly, you still can't overload the algebraic operators.
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 think that languages are pretty similar in so many ways that there's not much point in trying to claim one a clear winner. But personally I just find C# tries too hard to pack "just one more feature" in. There are things that definitely should have been left out; and in pretty much every case it's been one of mistakes C++ made. Operator overloading
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.
I disagree. Properties increase the number of entities you have to deal with - there used to be member values and member functions, now in C# you have memnber functions, member values and member properties. Many times in C# I find my code breaking because
The other thing with properties is that they look like fields, but don't work that way, for example, if B and C are implemented as properties, then this will not compile under C#:
A.B.C = someVal;
But this is not a problem with properties per se, but with the special implementation of properties in C#. I don't see a reason why an implementation of properties would not be able to allow that.
Function pointers and anonymous functions. This has got to be the biggest improvement over Java.
But this is not a problem with properties per se, but with the special implementation of properties in C#. I don't see a reason why an implementation of properties would not be able to allow that.
But we are talking about C#, and this is the behaviour that it has. And it cannot be implementation specific, unless you're telling me that Microsoft's implementation of C# is incorrect?
You are speaking about one specific application of function pointers, which indeed would be better solved with other concept
By giving it a name, you're essentially wasting time performing manual C++-style name mangling (for no reason at all).
No. Not at all. When you have:
list.map(<thing you can insert here>)
There is a relationship between map and the thing that you insert as a parameter. This relationship has meaning and the interface attaches a name to that meaning. This is the whole point of interfaces expressing a contract between objects and not being anonymous like the C example you gave.
What is that relationship? Can you come up with a good name for it? The map function is extremely generic and so there's no name you can give it that will provide any more useful information than its function signature.
Regarding maintainability... Traditionally the most common maintainability issues are caused when lazy programmers forget to document things or give variables uselessly short variable names. This is w
The other thing with properties is that they look like fields, but don't work that way, for example, if B and C are implemented as properties, then this will not compile under C#:
A.B.C = someVal;
Could you elaborate? I tried this and it worked for me:
class Test { . public static void Main() { . . A a = new A(); . . System.Console.WriteLine(a.b.c); . } } class A { . private B _b = new B(); . public B b { get { return _b; } } } class B { . private string _c = "Goose"; . public string c { get { return _c; } } }
class Test { . public static void Main() { . . A a = new A(); . . a.b.c = "Moose"; . . System.Console.WriteLine(a.b.c); . } } class A { . private B _b = new B(); . public B b { get { return _b; } set { _b = value; } } } class B { . private string _c = "Goose"; . public string c { get { return _c; } set { _c = value; } } }
It still works. I tested with both Mono and Microsoft's 1.1 SDK.
I just had a Post Grad Flash Back 20 years ago of a class in the Tuple Calculas. At the time, for me, it would have been better named, "Set Theroy, Gone Bad".
I'm thinking there are several languages that can return a Tuple. "C" programmmers call it a "Structure". Object Oriented programmers refer to the rules of a "Object Returned", or "Get, and Set". My personal favorite is PERL's "my ( x, y, z ) = someFunctionResult;"
I see a time when there will only be one language that will be used. This new lang
In programming languages, "tuple" usually means a record with anonymous fields that can be constructed on the fly. So Perl does have support for that (though things are a little different in dynamically typed languages because they don't even really have records in the first place).
In C, when you call functions, you are allowed to pass in tuples. That's why you can write:
// Declaration void CopyChars(StringBuffer src, StringBuffer dst, int length);
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.
IMHO the most important difference between the two languages is checked vs. unchecked exceptions. In my experience (from C++), unchecked exceptions are completely unusable in large projects. That's because it makes relying on documentation a necessity, which is of course a Bad Thing. This alone makes C# vastly inferior to Java in my book.
I code C# for a living (Score:4, Insightful)
Re:I code C# for a living (Score:5, Interesting)
Re:I code C# for a living (Score:3, Informative)
c# library vs Java library: c# is much cleaner in some aspects.
VS.net vs Eclipse: no contest, VS.net is much worse.
Re:I code C# for a living (Score:5, Informative)
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.
Re:I code C# for a living (Score:2)
I searched in wikipedia but algebra is quite far behind
thanks
Re:I code C# for a living (Score:5, Informative)
Suppose you have a class like this:
class A {
A method() { return new A() }
}
And another class like this:
class B extends A {
B method() { return new B() }
}
This construct is called covariant. The class B is ingeriting from A, while the method method() is overwritten in B. Not only is the mthod redefined but also the return value is. As it is redefined to the taype of the class, this is called covariant.
If the method in A would return a B and the method in B an A, it would be called contravariant.
For template parameters there are similar definitions, but they are a bit more complex.
angel'o'sphere
Re:I code C# for a living (Score:3, Informative)
In an OO language with objects and types we may say that a type, ST is a subtype of T.
The meaning of this is that an object of type ST can be used where an object of type T is expected.
Objects of type ST can have more operations (functions) than objects of type T, but it must have the same operations as objects of type T. These operations must have the same number of arguments and results as operations in T. But the arguments
Re:I code C# for a living (Score:3, Insightful)
Out parameters are mainly for use with API calls that return strings and such in reference paramters.
As far as I know, nowhere does the base class library use out paramters (I am sure there is somewhere, but it is probably o
Re:I code C# for a living (Score:2)
"Out" parameters are used to return more than one value. But "out" parameters are the wrong way to accomplish that. They are a holdover from the old C technique for faking multiple return values.
Re:I code C# for a living (Score:2)
Re:I code C# for a living (Score:2)
I am aware of this behavior, but it's not usually what the programmer requires. I'm betting that 99% of the time 'out' is used, the programmer doesn't rely on this weird behavior. All he wants is multiple return values. The other 1% of the time probably consists of things you shouldn't be doing anyway :)
The advantage of tuples is that they make things more general. C, Java and C# do have tuples. It's just that they're only allowed as arguments to functions. This limitation makes it really difficu
Re:I code C# for a living (Score:2)
Re:I code C# for a living (Score:2)
From my understanding, the out keyword in
Operator overloading (Score:4, Informative)
Just because operator overloading can be used for evil is no reason to throw the baby out with the bathwater.
Java lacks a Currency class, so I wrote a Money class some time ago that I use for common financial calculations, and it takes care of the pesky problem (and newbie mistake) of using floating point types for money.
BUT, in Java, you have to have add(), sub(), mult(), and div() methods. Reading RPN style caclulations consisting of sequenced and nested method calls instead of algebraic operators is painful. Operator overloading is wonderful in those cases.
Operator overloading certainly can be evil: What does it mean to increment an Employee? Do I really want to know? But for new types that you can actually do algebra with, it is quite helpful.
And there are other cases.
In my C++ days I wrote a FileHash class that kept an index of offsets to the start of each text line in a text file. Then I overloaded the array subscript operator so that a text file could used like an array of char pointers (or a String class if you liked). That was a perfectly good use of overloading.
Moreover I think overloading the array subscript on ordered collections also makes perfect sense.
I often wish Java had this feature. I agree with every simplifying choice they made except this one.
Re:Operator overloading (Score:2)
But even if you just handle one currency and can thus use BigDecimal directly, you still can't overload the algebraic operators.
Re:I code C# for a living (Score:1, Insightful)
I think that languages are pretty similar in so many ways that there's not much point in trying to claim one a clear winner. But personally I just find C# tries too hard to pack "just one more feature" in. There are things that definitely should have been left out; and in pretty much every case it's been one of mistakes C++ made. Operator overloading
Re:I code C# for a living (Score:3, Insightful)
I disagree. Properties increase the number of entities you have to deal with - there used to be member values and member functions, now in C# you have memnber functions, member values and member properties. Many times in C# I find my code breaking because
Re:I code C# for a living (Score:2)
But this is not a problem with properties per se, but with the special implementation of properties in C#. I don't see a reason why an implementation of properties would not be able to allow that.
Re:I code C# for a living (Score:2)
But we are talking about C#, and this is the behaviour that it has. And it cannot be implementation specific, unless you're telling me that Microsoft's implementation of C# is incorrect?
You are speaking about one specific application of function pointers, which indeed would be better solved with other concept
Re:I code C# for a living (Score:2)
You're leaving out the code you need to actually use the interface you created. This is how you'd do it if you had function pointers:
This is how you'd do it if you didn't:
Now, this could have been shorter if every function in java.lang.Math were actually a separate object t
Re:I code C# for a living (Score:2)
No. Not at all. When you have:
There is a relationship between map and the thing that you insert as a parameter. This relationship has meaning and the interface attaches a name to that meaning. This is the whole point of interfaces expressing a contract between objects and not being anonymous like the C example you gave.
Look, you either g
Re:I code C# for a living (Score:2)
What is that relationship? Can you come up with a good name for it? The map function is extremely generic and so there's no name you can give it that will provide any more useful information than its function signature.
Regarding maintainability... Traditionally the most common maintainability issues are caused when lazy programmers forget to document things or give variables uselessly short variable names. This is w
Re:I code C# for a living (Score:2)
Could you elaborate? I tried this and it worked for me:
W
Re:I code C# for a living (Score:2)
Dude, you did notice that none of those code lines was a case of
Note: it's an assignment to A.B.C, you only ever read the value of A.B.C - I didn't claim that that didn't work!
Re:I code C# for a living (Score:2)
Whoops, my mistake. I changed it to:
It still works. I tested with both Mono and Microsoft's 1.1 SDK.
Tuples? I Haven't Heard That in Years... (Score:1)
I'm thinking there are several languages that can return a Tuple. "C" programmmers call it a "Structure". Object Oriented programmers refer to the rules of a "Object Returned", or "Get, and Set". My personal favorite is PERL's "my ( x, y, z ) = someFunctionResult;"
I see a time when there will only be one language that will be used. This new lang
Re:Tuples? I Haven't Heard That in Years... (Score:2)
In programming languages, "tuple" usually means a record with anonymous fields that can be constructed on the fly. So Perl does have support for that (though things are a little different in dynamically typed languages because they don't even really have records in the first place).
In C, when you call functions, you are allowed to pass in tuples. That's why you can write:
Instead
Re:I code C# for a living (Score:1)
IMHO the most important difference between the two languages is checked vs. unchecked exceptions. In my experience (from C++), unchecked exceptions are completely unusable in large projects. That's because it makes relying on documentation a necessity, which is of course a Bad Thing. This alone makes C# vastly inferior to Java in my book.