Linked by Thom Holwerda on Mon 20th Jul 2009 15:54 UTC, submitted by Brandon L
As you would have guessed, the Mono debate is long from over. Two weeks ago, Microsoft extended its legally binding and perpetual community promise to cover the C# and CLI ECMA standards, which was generally seen as a good thing for Linux-centric fans of the C# language as well as for the Mono project. The FSF has responded now, and it isn't too impressed with Microsoft's move.
Thread beginning with comment 374223
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
RE: Who wants that crap anyway?
by google_ninja on Mon 20th Jul 2009 20:39
in reply to "Who wants that crap anyway?"
Member since:2006-02-05
The more proficient you are with a language, the more you recognize its warts.
First thing you need to do is buy resharper. Its been years since I have typed out a using statement, let alone worried if it was System.Collections, or Systems.Collections.Generic. If you are using a verbose language, IDE features for minimizing typing are gold, and resharper pretty much fills in the gaps that studio leaves.
I am not sure about your predicate issue (Filter is not a member of List<T>), but something like this works fine, even though the Find method signature has Predicate and not a Func.
var strings = new List<string>(new[] { "Foo", "Bar" });
var result = strings.Find(s => s == "Foo"); // result will equal "Foo"
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)
If you compare C# to something like C++ or java, it is fantastic (things like closures, implicit typing, verbose-yet-still-neat functional list processing). If you compare it to something like python, it is pretty damn clunky.
RE[2]: Who wants that crap anyway?
by tuttle on Mon 20th Jul 2009 21:37
in reply to "RE: Who wants that crap anyway?"
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 something like C++ or java, it is fantastic (things like closures, implicit typing, verbose-yet-still-neat functional list processing). If you compare it to something like python, it is pretty damn clunky.
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
RE: Who wants that crap anyway?
by Moochman on Mon 20th Jul 2009 20:56
in reply to "Who wants that crap anyway?"
Member since:2005-07-06
Another example: core .NET interfaces such as IEnumerable<T> are not in the system namespace but in the System.Collections.Generic namespace. So either you always use the long type name System.Collections.Generic.IEnumerabe<T>, or you always import all the crappy and badly named default collections of .NET.
I can only assume this is a prime example of how behind the times Visual Studio is compared to just about every Java IDE. Are you telling me you can't just type in the class and have a pop-up option automatically let you import it, without your hands leaving the keyboard or your cursor leaving the position? IntelliJ, NetBeans and Eclipse have had that feature for years....
RE[2]: Who wants that crap anyway?
by jpobst on Mon 20th Jul 2009 21:06
in reply to "RE: Who wants that crap anyway?"
Member since:2006-09-26
RE[2]: Who wants that crap anyway?
by tuttle on Mon 20th Jul 2009 21:10
in reply to "RE: Who wants that crap anyway?"
Member since:2006-03-01
"Another example: core .NET interfaces such as IEnumerable<T> are not in the system namespace but in the System.Collections.Generic namespace. So either you always use the long type name System.Collections.Generic.IEnumerabe<T>, or you always import all the crappy and badly named default collections of .NET.
I can only assume this is a prime example of how behind the times Visual Studio is compared to just about every Java IDE. Are you telling me you can't just type in the class and have a pop-up option automatically let you import it, without your hands leaving the keyboard or your cursor leaving the position? IntelliJ, NetBeans and Eclipse have had that feature for years.... "
Of course there is code completion. But code completion and automatic code generation does not make the code easier to understand.
The issue I have is that core interfaces like IEnumerable<T> are mixed with the collections library that I do not want to use.
This is just one example out of hundreds for bad design decisions.
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-03-01
The .net framework is less than 10 years old, yet it is full of cruft.
For example, .NET remoting is deprecated in favor of WCF, yet all the remoting related classes and interfaces are still present in the system namespace! Many of the core .net classes such as AppDomain inherit from MarshalByRefObject, which is obsolete due to remoting being obsolete.
Another example: core .NET interfaces such as IEnumerable<T> are not in the system namespace but in the System.Collections.Generic namespace. So either you always use the long type name System.Collections.Generic.IEnumerabe<T>, or you always import all the crappy and badly named default collections of .NET.
Next example: in .NET 2.0 collections have methods that take delegates such as List<T>.Filter(Predicate<T> x). In .NET 3.5 there are finally default generic functions, so a predicate would be of type Func<T,bool> (takes a T, returns a bool). But Func<T,bool> is not compatible with Predicate<T>, so if you have one and need the other you have to write an adapter.
I could write another 10 pages of these inconsistencies and bad design decisions. And the predominant .NET language C# could be used to write a book about the perils of nonorthogonality.
I have to work every single day with this crap. At least I get paid good money for it. But you would have to be a complete masochist to use .NET/C# for fun.