4 ms·

I understood Dijkstra to be arguing for simple languages, being more susceptible to formal proof, easier to understand, etc. Langauges like, say, C# are compli

by pmccool 16y ago

I understood Dijkstra to be arguing for simple languages, being more susceptible to formal proof, easier to understand, etc. Langauges like, say, C# are complicated _and_ patronising. That's the sort of language I thought the article was comparing Ruby with.

jemfinch 16y ago
> I understood Dijkstra to be arguing for simple languages, being more susceptible to formal proof, easier to understand, etc. Yes, he was. In a way, though, isn't Dijkstra's sort of "designing for simplicity" and even the goal of making a language "easier to understand" the very definition of "patronizing"?
- pmccool 16y ago
  I don't think so. For one thing, he wasn't just driving at "easier to understand", he was also after "easier to formally prove correct", which isn't at all patronising. I also don't find a goal of "easier to reason about" particularly patronising; it makes the rather un-patronising assumption that the target audience is willing and able to reason about the matter at hand. The language features I find patronising are the ones that make it hard to do things a certain way, regardless of how carefully considered my reasons are.
  - jemfinch 16y ago
    > The language features I find patronising are the ones that make it hard to do things a certain way, regardless of how carefully considered my reasons are. Any in particular that you have in mind? Historically, many people have had very carefully considered reasons for using features like goto, type puns, etc. but many languages exclude them as problematic. Is it patronizing to exclude such features even from the toolbox of programmers who carefully consider their use?
    - 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 understood Dijkstra to be arguing for simple languages, being more susceptible to formal proof, easier to understand, etc. Yes, he was. In a way, though, isn't Dijkstra's sort of "designing for simplicity" and even the goal of making a language "easier to understand" the very definition of "patronizing"?

pmccool 16y ago
I don't think so. For one thing, he wasn't just driving at "easier to understand", he was also after "easier to formally prove correct", which isn't at all patronising. I also don't find a goal of "easier to reason about" particularly patronising; it makes the rather un-patronising assumption that the target audience is willing and able to reason about the matter at hand. The language features I find patronising are the ones that make it hard to do things a certain way, regardless of how carefully considered my reasons are.
- jemfinch 16y ago
  > The language features I find patronising are the ones that make it hard to do things a certain way, regardless of how carefully considered my reasons are. Any in particular that you have in mind? Historically, many people have had very carefully considered reasons for using features like goto, type puns, etc. but many languages exclude them as problematic. Is it patronizing to exclude such features even from the toolbox of programmers who carefully consider their use?
  - 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.