4 ms·

My current least favourite patronising language feature: in C#, you can only override a method if the base class lets you. In answer to your second question, I

by pmccool 16y ago

My current least favourite patronising language feature: in C#, you can only override a method if the base class lets you. In answer to your second question, I think it depends. Including gotos in a language is problematic for reasons other than the fact that programmers tend to misuse them. I think it comes down to the rationale. With the C# feature I mentioned, the stated reason was, inter alia, that programmers tended to misuse inheritance. I found that patronsing. That leaving out goto makes it easier to formally prove a language correct I do not. Leaving out goto because programmers tend to misuse it, that I would find patronising.

jemfinch 16y ago
I apologize for not having the time to make this comment appear less like interrogation and more like a discussion ("if I had time, I would have written a shorter letter"), but I'm in a hurry :) Rest assured, I'm not arguing with you, but genuinely interested in your responses. > My current least favourite patronising language feature: in C#, you can only override a method if the base class lets you. My recollection from the design of Java is that such "finality" is necessary to allow the type system to reject code that attempts to override security-sensitive methods: is that not still true of C#? > I think it comes down to the rationale. With the C# feature I mentioned, the stated reason was, inter alia, that programmers tended to misuse inheritance. I found that patronsing. What of a language that eschews inheritance entirely, both because it makes reasoning about software more difficult and because the vast majority of programmers cannot use it correctly? "Patronizing" seems to indicate that a designer considered himself smart enough to use a feature, but determined his "subjects" were not. What of designers who recognize their own limitations and remove features they know to be error prone in their own practice of programming? Is that still patronizing, or does it deserve a different descriptor?
- pmccool 16y ago
  > My recollection from the design of Java is that such "finality" is necessary to allow the type system to reject code that attempts to override security-sensitive methods: is that not still true of C#? That's still true. The "feature" I has in mind is that methods in C# are not virtual by default. This is in direct contrast to Java where they are. This interview has a discussion on the motivation behind this (IMO incredibly tiresome) feature: http://www.artima.com/intv/nonvirtual.html http://www.artima.com/intv/nonvirtual.html. My view is that the real issue is that inheritance is all too often used when composition is more appropriate, which problem this change does nothing to help. > What of a language that eschews inheritance entirely, both because it makes reasoning about software more difficult and because the vast majority of programmers cannot use it correctly? If it only makes the language better for "bad" programmers, I would consider it patronising. It also comes down to the intent of the language designer, by definition. > "Patronizing" seems to indicate that a designer considered himself smart enough to use a feature, but determined his "subjects" were not. What of designers who recognize their own limitations and remove features they know to be error prone in their own practice of programming? Is that still patronizing, or does it deserve a different descriptor? I think that's worthy of a different descriptor. A failure to anticipate the needs of programmers who are smarter or more disciplined or whatever - which is what such an omission seems like to me - may be a problem, but I don't see it as patronising.

by pmccool 16y ago

jemfinch 16y ago

I apologize for not having the time to make this comment appear less like interrogation and more like a discussion ("if I had time, I would have written a shorter letter"), but I'm in a hurry :) Rest assured, I'm not arguing with you, but genuinely interested in your responses. > My current least favourite patronising language feature: in C#, you can only override a method if the base class lets you. My recollection from the design of Java is that such "finality" is necessary to allow the type system to reject code that attempts to override security-sensitive methods: is that not still true of C#? > I think it comes down to the rationale. With the C# feature I mentioned, the stated reason was, inter alia, that programmers tended to misuse inheritance. I found that patronsing. What of a language that eschews inheritance entirely, both because it makes reasoning about software more difficult and because the vast majority of programmers cannot use it correctly? "Patronizing" seems to indicate that a designer considered himself smart enough to use a feature, but determined his "subjects" were not. What of designers who recognize their own limitations and remove features they know to be error prone in their own practice of programming? Is that still patronizing, or does it deserve a different descriptor?

pmccool 16y ago
> My recollection from the design of Java is that such "finality" is necessary to allow the type system to reject code that attempts to override security-sensitive methods: is that not still true of C#? That's still true. The "feature" I has in mind is that methods in C# are not virtual by default. This is in direct contrast to Java where they are. This interview has a discussion on the motivation behind this (IMO incredibly tiresome) feature: http://www.artima.com/intv/nonvirtual.html http://www.artima.com/intv/nonvirtual.html. My view is that the real issue is that inheritance is all too often used when composition is more appropriate, which problem this change does nothing to help. > What of a language that eschews inheritance entirely, both because it makes reasoning about software more difficult and because the vast majority of programmers cannot use it correctly? If it only makes the language better for "bad" programmers, I would consider it patronising. It also comes down to the intent of the language designer, by definition. > "Patronizing" seems to indicate that a designer considered himself smart enough to use a feature, but determined his "subjects" were not. What of designers who recognize their own limitations and remove features they know to be error prone in their own practice of programming? Is that still patronizing, or does it deserve a different descriptor? I think that's worthy of a different descriptor. A failure to anticipate the needs of programmers who are smarter or more disciplined or whatever - which is what such an omission seems like to me - may be a problem, but I don't see it as patronising.