4 ms·

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 wit

by acabal 16y ago

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.

alanstorm 16y ago
Video production of a live event can be pretty easily automated. It's not no work, but once you're setup to do it it's pretty simple. Creating an accurate transcript of a live event is time consuming, and "hard" (well, it's tedious, which most people take to mean hard) to do right. Even if you don't any qualms crowd sourcing for something like this, you still need to manage the crowd sourcing, and get an edit cycle in there. TL;DR; Free things are free for a reason.
deleted 16y ago
[deleted]
dschobel 16y ago
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"?
- gtani 16y ago
  Excellent. Thanks for that. This is good thread also http://social.msdn.microsoft.com/Forums/en/csharplanguage/thread/47d10fcb-2d69-451a-bb97-023f1f9113f3 http://social.msdn.microsoft.com/Forums/en/csharplanguage/th...
- city41 16y ago
  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).
  - dschobel 16y ago
    His argument is that the concept of equality will vary by application and a default implementation adds very little. For example, does it make sense to test equality on a filestream? Probably not, but it's there and it purports to have some meaning. This of course, only makes sense in the post-generic world of .net +2.0 so he does excuse their presence as a vestige of 1.1.
    - city41 16y ago
      But simple equality often does make sense in the context of collections. Am I going to throw filestreams in a collection, probably not, but I very often throw all kinds of objects in a collection and the base object.Equals very often fits my needs there perfectly. I dunno, I haven't actually watched this presentation so maybe I just need more context. But I've been programming in C# since it came out and not once have I ever had any real issues with Equals and all of its related methods.
      - dschobel 16y ago
        I agree that as a practical matter it does what you want a majority of the time but generic collections let you mandate that an author has thought about equality for his object at least a little by implementing IEquatable. Particularly since a default definition of equality doesn't always make sense (as in the case of the fs). As with the case of explicitly sealed/unsealed classes, it seems like Jon's MO is to make programmers think about some of these things more carefully rather than have a "correct 90% of the time" default; a sentiment which I can definitely appreciate. :) Anyway, he discusses it at approximately the 36 minute mark. Well worth a look.

by acabal 16y ago

alanstorm 16y ago

Video production of a live event can be pretty easily automated. It's not no work, but once you're setup to do it it's pretty simple. Creating an accurate transcript of a live event is time consuming, and "hard" (well, it's tedious, which most people take to mean hard) to do right. Even if you don't any qualms crowd sourcing for something like this, you still need to manage the crowd sourcing, and get an edit cycle in there. TL;DR; Free things are free for a reason.

deleted 16y ago

[deleted]

dschobel 16y ago

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"?

gtani 16y ago
Excellent. Thanks for that. This is good thread also http://social.msdn.microsoft.com/Forums/en/csharplanguage/thread/47d10fcb-2d69-451a-bb97-023f1f9113f3 http://social.msdn.microsoft.com/Forums/en/csharplanguage/th...
city41 16y ago
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).
- dschobel 16y ago
  His argument is that the concept of equality will vary by application and a default implementation adds very little. For example, does it make sense to test equality on a filestream? Probably not, but it's there and it purports to have some meaning. This of course, only makes sense in the post-generic world of .net +2.0 so he does excuse their presence as a vestige of 1.1.
  - city41 16y ago
    But simple equality often does make sense in the context of collections. Am I going to throw filestreams in a collection, probably not, but I very often throw all kinds of objects in a collection and the base object.Equals very often fits my needs there perfectly. I dunno, I haven't actually watched this presentation so maybe I just need more context. But I've been programming in C# since it came out and not once have I ever had any real issues with Equals and all of its related methods.
    - dschobel 16y ago
      I agree that as a practical matter it does what you want a majority of the time but generic collections let you mandate that an author has thought about equality for his object at least a little by implementing IEquatable. Particularly since a default definition of equality doesn't always make sense (as in the case of the fs). As with the case of explicitly sealed/unsealed classes, it seems like Jon's MO is to make programmers think about some of these things more carefully rather than have a "correct 90% of the time" default; a sentiment which I can definitely appreciate. :) Anyway, he discusses it at approximately the 36 minute mark. Well worth a look.