|
Though C# has many great features, a handful could have been designed differently or omitted entirely. Best worst? Worst best?
|
|
|
|
|
|
The author is one of the Microsoft developers that wrote the original C# compiler. Though to be fair that doesn't mean he isn't a python developer.
I read this more as a list of "Here are 10 things I wish I could turn back time to fix, because we're stuck with them now."
|
|
|
|
|
Wow, I have just one comment.
Eric Lippert was a project leader on the C# compiler team, and a member of the C# language design team.
|
|
|
|
|
When Eric Lippert speaks about a language feature, a wise man listens.
|
|
|
|
|
|
Afzaal Ahmad Zeeshan wrote: lambda expression hatred
That's not the way I read it. It was more about not being able to "see the future".
Decrease the belief in God, and you increase the numbers of those who wish to play at being God by being “society’s supervisors,” who deny the existence of divine standards, but are very serious about imposing their own standards on society.-Neal A. Maxwell
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Your opinion, as you've probably gathered by now, is simply wrong.
He is quite clear that an empty statement is a bad idea - that is precisely why he wishes it wasn't there.
He didn't hate lambda expressions, he hated having two kinds of syntax for the same thing.
Next time, try reading the text between the headings as well 
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I don't mind any of the things he calls out, but then I'm developer not a language designer.
My pet peeves with C#, if I can recall them all, in no particular order:
C# v1 should have never seen the light of day. (Even though I have been a fan of C# since I saw the first published spec in 1999.)
The partial keyword to add back what has always been in C++ but which C# v1 lacked for no apparent reason. As in C++, all classes should be partial, no need for a keyword. What does non-partialness gain you?
Use of the this keyword for Extension Methods, rather than the simple direct use of the Attribute. (Just do what VB does.)
The sillyness of being able to eliminate the "Attribute" part of an Attribute name. Why? To save a few keystrokes? So why not also allow us to drop the "Exception" part of an Exception name? Don't you write a lot more Exceptions and handlers than Attributes? catch (NullReference err)...
The inability to specify enum as a generic constraint. (Jon Skeet has written about this too.)
If enum values are always numeric, then why not allow numeric operations on them? The compiler knows what they are. If a member of an enum IS_AN int, then let it do what an int can do!
Add: An ISNT (or AINT) operator so we don't have to do if ( !( x is y ) )...
modified 19-Aug-15 13:11pm.
|
|
|
|
|
"As in C++, all classes should be partial"
Actually, I'd love to see partial classes in C++. Being able to define members in a separate file is not the same thing as being able to add members in a separate file at all.
It would be very helpful for cases such as machine-generated code, where the class definition could reside in two places, one of which is machine-generated, and does not overwrite the one that has been edited by the user.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I'm going to be mildly contrary and say that I wish I knew that this:
if (condition)
{
;
}
was legal years ago. When I tried putting conditional breakpoints inside hot loops in VS2010 I saw order of magnitude slowdowns (from ~100k to 10k iterations/second). Putting a breakpoint on this slightly larger kludge:
int foo;
if (condition)
{
foo = 1;
}
OTOH had almost no impact on throughput. The project in question has been over for many years now; and I haven't do anything that heavily compute bound since so it's possible newer versions of VS have removed the performance penalty but getting so badly burned a few years ago left a really bad taste in my mouth.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I don't use it, but back in my Pascal days I would insert extra semi-colons because I had a utility that would count them to determine how many statements were in a program.
Nowadays, when I use the debugger (VS 2012), I often put breakpoints on closing BRACEs.
|
|
|
|
|
Directory.GetFiles!!! Haven't looked yet, but it has to be there.
It's totally blocked until it returns.
Directory.GetFiles() has my vote!!
I remember you FindFirstFile, FindNextFile API and I remember you fondly. 
|
|
|
|
|
Well, that's not a feature of C#, so much as a feature of the framework.
|
|
|
|
|
Yes, you are right, of course.
I got excited to be able to complain to someone about Directory.GetFiles().
I like C# because it is like a friendly version of The Best Language in the Entire Universe: C++
Let the language-wars begin!
|
|
|
|
|
|
I always forget about that one because it is new -- added in .NET 4.0. 
It is a bit different from the original FindFirstFile too -- you could easily cancel the work of enumeration on the original one. This call just seems to run. How would you cancel it?
However you have inspired me to work with this method and learn more about it.
It is interesting since it could run on one thread I suppose and you could iterate the list on another thread?
|
|
|
|
|
newton.saber wrote: How would you cancel it?
Usually by terminating a loop.
newton.saber wrote: iterate the list on another thread?
Or several if you like.
|
|
|
|
|
I can't do anything else than approving the termination of the unary plus operator
I fully agree on the IEquatable<> and IComparable<> interfaces implementation nightmare; considering the fact that we have to deal with structs and classes differently, we end up with four different ways to do basically the same thing.
I also agree on the fact that two concepts that do not overlap should not be implemented in a single object (ex: integers/bit arrays, enums/flagged enums). Having a consistent system for bit-arrays handling would be a great improvement.
I had never imagined that using increment and decrement operators could be a problem. I use them pretty much. Maybe there are better ways to achieve the same goals, but I never had a readability problem with them; they just make a lot of simple expressions very concise.
It would also be very painful to me if I had to give up on the for loop.
while (true) {
continue;
}
|
|
|
|
|
phil.o wrote: I also agree on the fact that two concepts that do not overlap should not be implemented in a single object (ex: integers/bit arrays, enums/flagged enums). Having a consistent system for bit-arrays handling would be a great improvement.
I see this a lot, but they do overlap. A lot of the power of using an int as a bitarray comes from the ability to use operations that aren't strictly bitwise, for example x & -x selects the lowest set bit (if there is one) without having to look for it,
x & x - 1 removes the lowest set bit (used also as part of determining whether a number is a power of two), or to take a more practical turn, the o^(o-2r) trick in chess engines.
Meanwhile integers that we pretend aren't bitarrays (they still are) benefit from bitwise operations, for example testing whether it's a power of two (as above), rounding up/down until it is a power of two (involves a bunch of shift/or), rounding down to a known power of two (eg x & -16 is the canonical way to round x down to a multiple of 16), and even knocking off the lowest set bit (as above) in the indexing of a Fenwick tree (it's not a bag of bits there, it's an index), the FFT bitreversal (again an index, not a bag of bits).
Arithmetic operations and bitwise operations are not two different worlds, they mix in useful ways.
|
|
|
|
|
phil.o wrote: termination of the unary plus operator
NO! That would violate the Orthogonality Principle! (Or is it the Regularity Principle?)
Heathens at the gate! Heathens at the gate!
|
|
|
|
|
I'm surprised there's nothing on the overuse of ?.
MyClass item = passedIn != sentinel ? otherItem : defaultValue;
item = item ?? otherCouldBeNullValue;
item?.DoSomething();
|
|
|
|
|
Pete O'Hanlon wrote: MyClass item = passedIn != sentinel ? otherItem : defaultValue;
Should the inverted question mark, unicode U+BF ¿ flip the sense of the boolean?
Pete O'Hanlon wrote: item = item ?? otherCouldBeNullValue;
Why doesn't unicode U+2047 ⁇ work like the double ?
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed."
- G.K. Chesterton
|
|
|
|
|
You mean that several various operators contain a question mark? Meh, I'm OK with that -- at least until I see
MyClass item = someitem ?? otherCouldBeNullValue != sentinel ? otherItem?.DoSomething() : defaultValue;
I don't blame the designers for abuse.
|
|
|
|
|
Exactly - and you know that sooner or later people will start accepting R# suggestions that end up producing horrors like that.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
This first section of the post told me that the developer was indeed a python lover, I hope python engulfs him soon. 
