Ending the Era of Patronizing Language Design • Hacker News Board

Re: Ending the Era of Patronizing Language Design

#31

Post by jrockway » Fri, May 21, 2010, 7:22 PM UTC

Tamerlin wrote: post #22

btilly wrote: post #11

He admits that he doesn't know Ruby deeply, but then he goes on to assert that Ruby people don't seem to create messes that paint themselves into corners. From what I've read plenty of people have done just that in Ruby because of monkeypatching.

My first Ruby programming experience was with a company sunk by Rubyists, their asinine architecture, and constant monkey-patching. Rubyists most certainly DO hang themselves with monkeypatching, quite often. You just don't tend to hear about the ones that to that, because the sites they build that way don't survive long enough for anyone to notice, assuming that they even launch them successfully, which is rare. I t…

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 in the financial sector. Ruby is something people learn because they think programming is cool. (Admittedly, the Ruby community's aggressive marketing has gotten a lot of people that shouldn't be programming into programming, and that's bad for their community. But wanting to be a cool Rubyist like _why causes a lot less damage than wanting to have a high-paying job.)

Anyway, Ruby is fine when used by someone with a clue. C++, not so much.

Re: Ending the Era of Patronizing Language Design

#32

Post by jemfinch » Fri, May 21, 2010, 7:47 PM UTC

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)

Re: Ending the Era of Patronizing Language Design

#33

Post by jmillikin » Fri, May 21, 2010, 7:51 PM UTC

cabalamat wrote: post #23

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. Really? I was coding C++ using multiple inheritance and operator overloading around then, and AFAICT was using them properly.

Sorry; I meant language designers didn't know how to use them. C++ is a perfect example of operator overloading gone horribly wrong.

Re: Ending the Era of Patronizing Language Design

#34

Post by JulianMorrison » Fri, May 21, 2010, 8:47 PM UTC

barrkel wrote: post #6

From the outset, I'm aware that programmers who haven't tried to design programming languages will likely disagree with me; but I'll express what I've learned anyway. The truth, from the language designer and compiler author's perspective: programmers should be protected from their own worst instincts, and programming languages that do this well are of a higher quality than languages which don't. Patronizing, to a po…

For what it's worth, some "patronizing" limits actually enable optimizations that are otherwise not possible.

For example, if anything might be a pointer and you can point to an offset inside a struct, then you can't have deterministically perfect garbage collection and you can't have garbage collection that moves things, for example to compact the heap. Java solves this by only allowing references to "the top of" objects, and stopping you casting pointers. Consequently, Java's runtime knows what's garbage and it can move things around with impunity.

Or consider Clojure, where immutable data means that you can grab a snapshot of a value without read-locking.

Re: Ending the Era of Patronizing Language Design

#35

Post by rue » Fri, May 21, 2010, 9:39 PM UTC

btilly wrote: post #11

He admits that he doesn't know Ruby deeply, but then he goes on to assert that Ruby people don't seem to create messes that paint themselves into corners. From what I've read plenty of people have done just that in Ruby because of monkeypatching.

> He admits that he doesn't know Ruby deeply, [...] From what I've read plenty of people have done just that [...]

Your argument seems to have a slight inconsistency.

Re: Ending the Era of Patronizing Language Design

#36

Post by lmkg » Fri, May 21, 2010, 9:46 PM UTC

hernan7 wrote: post #29

Artemidoros wrote: post #25

Earlier quoted context omitted.

I've been coding in Ruby/Rails for 3 years now, and been active in the community, and I haven't yet done that or encountered anyone who had done that. Than you seem to have had much more luck than I did.

Grammar nitpick: That would be "then", not "than" (this particular error never fails to gum up my non-native English spearker's parser).

Nitpick nitpick: This statement refers to the first "than," not the second, which is used correctly.

Re: Ending the Era of Patronizing Language Design

#37

Post by jules » Fri, May 21, 2010, 9:52 PM UTC

jmillikin wrote: post #18

j_baker wrote: post #15

Earlier quoted context omitted.

Interesting points, but I think you're bordering on straw manning the author. I'll grant you that maybe C++ is about as bad an example as you can get of putting responsibility in the hands of the programmer. In fact, it was behind a lot of Java's decision to take that power out of the developers' hands. I would argue that Java was an overreaction. It corrected the safety issues, but also removed a lot of the ability…

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. You arrive at the simple (just use the lexical ordering of the superclass list) or the more complex (Dylan's method ordering, now also in Python) purely by reasoning logically. I'm pretty sure someone like Guy Steele would be able to figure this out.

Operator overloading: what could possibly be worse than x.multiply(y)? You either have a fixed list of operators that you can override by defining a method in a class, or you have an expandable set of operators for which you can specify the precedence and which way it associates. This is not a hard problem.

Re: Ending the Era of Patronizing Language Design

#38

Post by pmccool » Fri, May 21, 2010, 10:02 PM UTC

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.

Re: Ending the Era of Patronizing Language Design

#39

Post by Artemidoros » Fri, May 21, 2010, 10:25 PM UTC

hernan7 wrote: post #29

Artemidoros wrote: post #25

Earlier quoted context omitted.

I've been coding in Ruby/Rails for 3 years now, and been active in the community, and I haven't yet done that or encountered anyone who had done that. Than you seem to have had much more luck than I did.

Grammar nitpick: That would be "then", not "than" (this particular error never fails to gum up my non-native English spearker's parser).

Thanks!

Re: Ending the Era of Patronizing Language Design

#40

Post by Tamerlin » Fri, May 21, 2010, 10:31 PM UTC

jrockway wrote: post #31

Tamerlin wrote: post #22

Earlier quoted context omitted.

My first Ruby programming experience was with a company sunk by Rubyists, their asinine architecture, and constant monkey-patching. Rubyists most certainly DO hang themselves with monkeypatching, quite often. You just don't tend to hear about the ones that to that, because the sites they build that way don't survive long enough for anyone to notice, assuming that they even launch them successfully, which is rare. I t…

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 management, they'd have been fired.

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.

However, given one of the jobs I received e-mail about, I'd say that the salaries that rubyists can get puts them in the worst of both worlds -- it attracts people who want to be cool, and people who want high-paying jobs. Plus, it's easy to learn badly, which sets the bar very low.