Linked by Thom Holwerda on Mon 20th Jul 2009 15:54 UTC, submitted by Brandon L
Thread beginning with comment 374255
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Who wants that crap anyway?
by google_ninja on Tue 21st Jul 2009 00:41
in reply to "RE[2]: Who wants that crap anyway?"
By the way: that the list handling functions are called differently than in all other languages is another bad design decision: ConvertAll instead of Map, FindAll instead of Filter etc.
IMO that is hands down the worst thing about MS, their tunnel vision and inability to look outside of redmond.
At least most language features of java work well with other language features. Half of C#'s language features are no longer usable if you for example use generic types: no operators, no static methods etc.
I wouldn't say half, but yes, there are some, and yes, that sucks when you run into it. However, I would rather have features that work fine in the 80%-90% case rather then not have them at all.
The few interfaces they do provide in .net (e.g. IEquatable<T>) are not even consistently used by the basic language constructs (e.g. enums do not implement IEquatable).
I find in general, the java core libs are over engineered, to the point where you need to do boatloads of implementation to get the smallest thing done, while the .net core libs are under engineered.
If you compare C# to a modern JVM language like scala it looks like a toy. And C++ allows a much higher level of abstraction than C# ever will because of template metaprogramming.
Agree 100% with scala, I do not with C++.
Every single language feature of C# looks pretty neat in small examples. But whenever you dig a bit deeper you see that that is all just a facade. To every rule there are hundreds of exceptions. Properties look just like fields, but you can not use ref parameters with properties. Every abstraction is leaky.
Again, I see where you are coming from, but how often do you do ref parameters?
I've run into some of the things you mentioned as well, but again, it is a once in awhile thing, and overall I find having it work the majority of the time the way I want to is better then not having it at all. Events vs anonymous types? Automatic properties vs getter and setter methods? foreach vs for? Typed exceptions? Closures? LINQ vs loops? Implicit typing (as crappy an implementation as it is) vs even more verbosity?
I am not saying C# is the be all or end all by any stretch of the imagination. Scala I think puts pretty much every systems language that came before it to shame. But I would rather use c# then java, and I would rather use java then c++.
RE[4]: Who wants that crap anyway?
by tuttle on Tue 21st Jul 2009 09:40
in reply to "RE[3]: Who wants that crap anyway?"
"By the way: that the list handling functions are called differently than in all other languages is another bad design decision: ConvertAll instead of Map, FindAll instead of Filter etc.
IMO that is hands down the worst thing about MS, their tunnel vision and inability to look outside of redmond.
"
Something we can agree on. They should just ask somebody from microsoft research like Simon Peyton-Jones on questions like these.
By the way: that is one of the many advantages of scala. Martin Odersky (the creator of scala) does not leave writing collection classes to some intern. He does it himself.
"The few interfaces they do provide in .net (e.g. IEquatable) are not even consistently used by the basic language constructs (e.g. enums do not implement IEquatable).
I find in general, the java core libs are over engineered, to the point where you need to do boatloads of implementation to get the smallest thing done, while the .net core libs are under engineered.
"
Then maybe I just prefer overengineered to underengineered. For example in swing, the pervasive use of MVC makes writing small applications a bit tedious sometimes. But writing a big application without MVC is a major torture.
Maybe I should just write less big applications :-)
"If you compare C# to a modern JVM language like scala it looks like a toy. And C++ allows a much higher level of abstraction than C# ever will because of template metaprogramming.
Agree 100% with scala, I do not with C++.
"
As long as we agree on scala, we can agree to disagree on C++. But C++ is very powerful if used correctly. It is just very easy to shoot yourself in the foot with it.
"Every single language feature of C# looks pretty neat in small examples. But whenever you dig a bit deeper you see that that is all just a facade. To every rule there are hundreds of exceptions. Properties look just like fields, but you can not use ref parameters with properties. Every abstraction is leaky.
Again, I see where you are coming from, but how often do you do ref parameters?
"
Every time I use one of the various TryParse or TryGetValue methods?
I've run into some of the things you mentioned as well, but again, it is a once in awhile thing, and overall I find having it work the majority of the time the way I want to is better then not having it at all. Events vs anonymous types? Automatic properties vs getter and setter methods? foreach vs for? Typed exceptions? Closures? LINQ vs loops? Implicit typing (as crappy an implementation as it is) vs even more verbosity?
I am not saying C# is the be all or end all by any stretch of the imagination. Scala I think puts pretty much every systems language that came before it to shame. But I would rather use c# then java, and I would rather use java then c++.
I am not saying C# is the be all or end all by any stretch of the imagination. Scala I think puts pretty much every systems language that came before it to shame. But I would rather use c# then java, and I would rather use java then c++.
For me it's scala, java, C++, C#. For a project with lots of mediocre programmers or one that does not require high performance, I would put C++ last.
RE[3]: Who wants that crap anyway?
by iliks on Tue 21st Jul 2009 11:52
in reply to "RE[2]: Who wants that crap anyway?"
The .net framework does not even provide an interface for a set.
There is the HashSet class that implements sets.
public class HashSet<T> : ICollection<T>, IEnumerable<T>,
IEnumerable, ISerializable, IDeserializationCallback
Various set-related functions are available as extension methods in the IEnumerable<T> interface.
Edited 2009-07-21 11:58 UTC





Member since:
2006-03-01
I am not sure about your predicate issue (Filter is not a member of List), but something like this works fine, even though the Find method signature has Predicate and not a Func.
var strings = new List(new[] { "Foo", "Bar" });
var result = strings.Find(s => s == "Foo"); // result will equal "Foo"
That is not what I meant. If you have a delegate of type Predicate but need a delegate of type Func or vice versa, you have to write an adapter. That can be as simple as a small lambda expression like the one above, but it comes with considerable performance cost and is also quite ugly.
By the way: that the list handling functions are called differently than in all other languages is another bad design decision: ConvertAll instead of Map, FindAll instead of Filter etc.
Lastly, if you want pain, work with java for a bit. All these "enterprisey" languages accumulate amazing mounts of cruft, because they have promise support for a bajillion years for anyone to think of using it. Your options are keep bolting things on as nicely as you can (C#), or just don't add anything to the language, even when it gets horribly out of date (java)
At least most language features of java work well with other language features. Half of C#'s language features are no longer usable if you for example use generic types: no operators, no static methods etc.
And at least the java class library contains some decent collections. The .net framework does not even provide an interface for a set. And there is not even a default implementation of the most basic concurrency data structure: a blocking queue.
The few interfaces they do provide in .net (e.g. IEquatable<T>) are not even consistently used by the basic language constructs (e.g. enums do not implement IEquatable).
If you compare C# to a modern JVM language like scala it looks like a toy. And C++ allows a much higher level of abstraction than C# ever will because of template metaprogramming.
Every single language feature of C# looks pretty neat in small examples. But whenever you dig a bit deeper you see that that is all just a facade. To every rule there are hundreds of exceptions. Properties look just like fields, but you can not use ref parameters with properties. Every abstraction is leaky.
Edited 2009-07-20 21:48 UTC