

C#'s Greatest Mistakes by Jon Skeet - adambyrtek
http://oredev.org/2010/sessions/c-s-greatest-mistakes

======
acabal
I really wish people would include transcripts if they're going to post a
48-minute long video. There's no way I'm going to sit through something like
that without at least a bullet-point text summary.

~~~
dschobel
not a transcript but some notes of his wishes and complaints for the language.

\----------------------------------

wish: static interfaces for use in the context of generic type constraints

    
    
        static interface ISummable<T>
        {
            T operator +(T arg1, T arg2);
        }
    
      which then lets you write
    
        static T Sum<T>(IEnumerabel<T> source) where T : ISummable<T> { }
        

\----------------------------------

gripe: array covariance (which the designers copied from java even though
people knew it was a mistake even when java had it):

    
    
        //the following is still valid and will happily compile and run
        string[] strings = new string[5];
        object[] objects = strings;
        objects[0] = new Exception();
    

\----------------------------------

wish: non-nullable references (ackowledges that it is a hard problem but "it
would be nice to have")

\----------------------------------

wish/gripe: c# enums are labels for numbers which let you write things like:

    
    
                enum Color {red = 0, green = 1, blue =2}
                Color c = (Color) 5;
                Color c2 = 0.0;
    

he wants to see java-like enums which enforce the idea that you're dealing
with a restricted set of values.

\----------------------------------

wish: Read-only keyword for auto-properties

.net 3 made it easy to tack mutable properties onto your class

    
    
            string Name{get;set;}
    

Jon wants to see:

    
    
        string Name{ readonly get; }
    

which tells the world that not only is Name immutable externally to your
class, but internally as well.

    
    
        string Name { get; private set; } 
    

does not get you there, since the property is still fully mutable within your
class.

\----------------------------------

wish: sealing/unsealing classes

this was his self-proclaimed controversial point

he either wants to see classes sealed by default and then unsealed with an
explicit 'unsealed' keyword or he wants the default class template in Visual
Studio to demand that the programmer pick one or the other

\----------------------------------

gripe: object is bloated, cut Equals() and HashCode()

writing equals in a type hierarchy is a pain and gets messy when you drill
down into the derived types

let authors "opt in" to equality

want a map of <T>? or a dictionary of <T>? you have to provide an equality
comparer

"there doesn't have to be one canonical idea of equality for a type so why is
it in object"?

~~~
city41
Object is bloated? That's an odd complaint. Much like array covariance, object
was pretty much directly copied from Java.

I disagree on getting rid of Equals if for no other reason it's implicitly
used often (like in collections). And if there is no canonical idea of
equality, that's what overriding Equals is for, and what
Object.ReferenceEquals is for (return yourself to the base notion of equality
when you need it).

~~~
skybrian
It's a mistake in Java too. It's often convenient to simply skip implementing
equals() and hashCode() because you don't plan to use an object as the key to
a map. In that case, attempting to use it as a key should fail to compile, so
you know you need to go back and add it.

The Comparable interface shows how it should be done.

(But on the other hand, if you were starting over it would be better to learn
from Go's interfaces.)

~~~
jpr
Uh oh, I wouldn't want anyone to copy anything that has to with typesystem
from Go before they tell how they are going to have typesafe containers
without generics. Haskell typeclasses would be a better source of inspiration
IMNSHO.

------
wccrawford
I didn't watch it, but somehow I think I could have digested the information a
lot quicker than watching a 48 minute video. A nice webpage or document, maybe
with a few code snippets, and it would be much quicker to take in and
understand, I'm sure.

~~~
bruceboughton
Sure, but this is a conference presentation.

------
stephen
"While his day job primarily involves Java code, Jon is a huge C# enthusiast."

Nice. I wonder what he thinks of stab:

<http://code.google.com/p/stab-language/>

So far, stab is a 1-man hobby project, but the guy seems incredibly prolific.
Besides the compiler, he recently started work on an Eclipse plugin as well.

~~~
nsoonhui
Who do you expect; he's Jon Skeet the No. 1 contributor on StackOverflow

------
joe_the_user
I watched the first twenty minutes.

One interesting take-away was "languages should support good habits and make
anti-patterns harder" (paraphrased roughly, of course). So it comes down to
what one thinks good or bad habits are.

The video further reminded me of C#/.net's ginormous number of classes,
interfaces and intermediate classes - it is standard procedure to use three
different class-types to get a row of data from a database query. Thus my view
would be that c#'s many clever looping and generics patterns actually are
enabling tools the anti-pattern of too many classes/excessive indirection.

Thus it seems like Ruby's "Duck-typing", where you pass a single array around
even when it's used slightly differently all around, is a general approach
which allows you to escape this hell.

