Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ending the Era of Patronizing Language Design

blog.objectmentor.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Ending the Era of Patronizing Language Design

#51

Post by jrockway »

Tamerlin wrote: post #40
jrockway wrote: post #31

Earlier quoted context omitted.

You're confused. Rubyists didn't sink your project. Bad programming (and management) did. They would have fucked up the project in Java or Haskell or Perl or anything else. Oh, and having interviewed C++ developers, I am not sure I can agree that the average C++ programmer is of higher caliber than the average Ruby programmer. C++ is something that these people learn because they think they will get a high-paying job…

"You're confused. Rubyists didn't sink your project. Bad programming (and management) did. They would have fucked up the project in Java or Haskell or Perl or anything else." I'm not confused at all. Rubyists sunk the project, plain and simple. I actually still like Ruby, because I had a chance to do some cool stuff with it before our inferior rubyists wrought their havoc, and I agree that had we had decent managemen…

My only criticism of Ruby is that because it's easy, it allows vastly inferior programmers to program, which lowers the bar drastically. I believe that a number of the other senior developers there won't touch ruby at all now, I'm not one of those.

Wrong. Every language allows this. Have you ever read enterprise Java or C++ code?

Re: Ending the Era of Patronizing Language Design

#52

Post by crystalis »

jules wrote: post #37
jmillikin wrote: post #18

Earlier quoted context omitted.

Java supports global variables just fine -- in fact, most Java code uses far too many globals for my taste. Multiple inheritance and operator overloading aren't bad , but at the time Java was designed, nobody had any idea how to use them properly. Python 2 gets MI right (though Py3 fucks it up a bit with magical super()), and Haskell provides a clean implementation of overloading, but it'll be years before these impr…

> Multiple inheritance and operator overloading aren't bad, but at the time Java was designed, nobody had any idea how to use them properly. It's not hard to figure out a better the way to do it than not doing it at all with a few hours thought. And in fact Dylan got both multiple inheritance and operator overloading right before Java existed. Method ordering is the most significant problem with multiple inheritance.…

There are two problems - everything that you add distracts the human elements, and adds some computational cost.

The human element ranges pretty far, from the neophile trying to grasp every piece, the seasoned veteran evaluating a new language, the maintainer considering what part to improve, or what patch to consider, and so on.

Not every lawn needs a thousand pink flamingos, even if they're better than no flamingos at all.

Re: Ending the Era of Patronizing Language Design

#53

Post by jemfinch »

pmccool wrote: post #38
jemfinch wrote: post #32

It's not about being patronizing. It's about recognizing our human limitations: "As a slow-witted human being I have a very small head and I had better learn to live with it and to respect my limitations and give them full credit, rather than try to ignore them, for the latter vain effort will be punished by failure." (Dijkstra, EWD249)

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.

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

Re: Ending the Era of Patronizing Language Design

#54

Post by pmccool »

jemfinch wrote: post #53
pmccool wrote: post #38

Earlier quoted context omitted.

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.

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

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.

Re: Ending the Era of Patronizing Language Design

#55

Post by jemfinch »

pmccool wrote: post #54
jemfinch wrote: post #53

Earlier quoted context omitted.

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

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

Re: Ending the Era of Patronizing Language Design

#56

Post by pmccool »

jemfinch wrote: post #55
pmccool wrote: post #54

Earlier quoted context omitted.

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 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 to…

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.

Re: Ending the Era of Patronizing Language Design

#57

Post by jemfinch »

pmccool wrote: post #56
jemfinch wrote: post #55

Earlier quoted context omitted.

> 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 to…

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 te…

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?

Re: Ending the Era of Patronizing Language Design

#58

Post by pmccool »

jemfinch wrote: post #57
pmccool wrote: post #56

Earlier quoted context omitted.

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 te…

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…

> 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.

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.

Re: Ending the Era of Patronizing Language Design

#59

Post by Tamerlin »

jrockway wrote: post #51
Tamerlin wrote: post #40

Earlier quoted context omitted.

"You're confused. Rubyists didn't sink your project. Bad programming (and management) did. They would have fucked up the project in Java or Haskell or Perl or anything else." I'm not confused at all. Rubyists sunk the project, plain and simple. I actually still like Ruby, because I had a chance to do some cool stuff with it before our inferior rubyists wrought their havoc, and I agree that had we had decent managemen…

My only criticism of Ruby is that because it's easy, it allows vastly inferior programmers to program, which lowers the bar drastically. I believe that a number of the other senior developers there won't touch ruby at all now, I'm not one of those. Wrong. Every language allows this. Have you ever read enterprise Java or C++ code?

Actually it's entirely true. Ruby allows VASTLY inferior programmers to program. Java and C++ set slightly higher bars; at least with them you have to reach inferior, as opposed to vastly inferior, in order to make stuff work.
Post reply on HN