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

21–30 of 59 posts

Re: Ending the Era of Patronizing Language Design

#21

Post by Artemidoros »

So, why aren’t more people crashing and burning?

because:

a) You're awesome, as long as you're using Ruby no matter how ridiculous you look when seen without rainbow colored glasses - http://www.infoq.com/presentations/ford-large-rails

b) The "you're doing it wrong crowd" will shout you down the moment you admit having troubles - http://glu.ttono.us/articles/2007/04/15/on-twitter-rails-and...

c) Most failed Ruby (which in all fairness usually means Rails) projects never gain any publicity.

d) Ruby projects coming close to the gargantuan scope of some of the bigger Java projects are (thankfully) exceedingly rare (if not non existent).

Lastly I had no clue that Saeed al-Sahaf is now working for Object Mentor, awesome!

Disclaimer: I worked for 3 years as a Ruby developer, including on one of the bigger (> 50.000 loc) Rails projects out there and I encountered some crashing and burning myself (I know I did it wrong).

Re: Ending the Era of Patronizing Language Design

#22

Post by Tamerlin »

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 think in fact that because Ruby is a much more forgiving language than, say, C++ (the same goes for Python), the average caliber of Ruby developers is FAR lower than the caliber of, say, C++ and Lisp developers. My experience with Ruby and Python developers hasn't been positive -- in fact, working at a Python shop gave me an intense distaste for the language, and my experience at a Ruby shop lead to similar sentiments among a lot of the senior developers who worked there.

Re: Ending the Era of Patronizing Language Design

#23

Post by cabalamat »

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.

Really? I was coding C++ using multiple inheritance and operator overloading around then, and AFAICT was using them properly.

Re: Ending the Era of Patronizing Language Design

#24

Post by Tamerlin »

swombat wrote: post #16
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.

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. People are warned that monkey-patching is dangerous, they learn how to monkey-patch responsibly, and they act accordingly and responsibly - if something does go wrong with monkey-patching (which, as I've said, seems not to happen), the person who did the patching is aw…

So YOU'RE the one! :)

Re: Ending the Era of Patronizing Language Design

#25

Post by Artemidoros »

swombat wrote: post #16
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.

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. People are warned that monkey-patching is dangerous, they learn how to monkey-patch responsibly, and they act accordingly and responsibly - if something does go wrong with monkey-patching (which, as I've said, seems not to happen), the person who did the patching is aw…

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.

Re: Ending the Era of Patronizing Language Design

#26

Post by jamesbritt »

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.

"From what I've read plenty of people have done just that in Ruby because of monkeypatching."

Tends to be the people who think of modifying open classes as "monkeypatching" who fuck it up because they still see it as some sort of quirk in the language rather than just another part of the language ecosystem.

Re: Ending the Era of Patronizing Language Design

#27

Post by jamesbritt »

Zarkonnen wrote: post #4

The problem with saying "you can do things in whatever way you want in Ruby" is that the moment you have more than one developer it collides rather drastically with the "principle of least astonishment". This is not to say that making everything out of eg Java boilerplate is the solution. The key is writing well-behaved and consistent code, which you can do in most languages.

    The problem with saying "you can do things in whatever 
    way you want in Ruby" is that the moment you have more
    than one developer it collides rather drastically with 
    the "principle of least astonishment".
I've solved that problem by actually talking with the other developers and agreeing to some common practices.

Not every problem requires a technical solution. Social solutions often work just fine.

Re: Ending the Era of Patronizing Language Design

#28

Post by jrockway »

swombat wrote: post #16
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.

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. People are warned that monkey-patching is dangerous, they learn how to monkey-patch responsibly, and they act accordingly and responsibly - if something does go wrong with monkey-patching (which, as I've said, seems not to happen), the person who did the patching is aw…

But the problem is that all the hacks that don't poorly affect one module do poorly affect the composition of modules. Remember how you can't use Rails and some full-text indexing package because they both monkey-patch Array differently? That's a major problem.

Ruby programmers get themselves into plenty of trouble. Of course, so do Java programmers, or any other programmers. The problem is people, not programming language features. (Except manual memory management, as per C. That's a language problem.)

Re: Ending the Era of Patronizing Language Design

#29

Post by hernan7 »

Artemidoros wrote: post #25
swombat wrote: post #16

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. People are warned that monkey-patching is dangerous, they learn how to monkey-patch responsibly, and they act accordingly and responsibly - if something does go wrong with monkey-patching (which, as I've said, seems not to happen), the person who did the patching is aw…

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

Re: Ending the Era of Patronizing Language Design

#30

Post by prodigal_erik »

Rickasaurus wrote: post #12

I like the idea of having the freedom to do everything but also having intelligent defaults to nudge the programmers in the right direction. Optional immutability is a great example of this. When you make something the default, you send the message "this is usually the right way to go about things".

When immutability is optional, you can no longer rely on it to reason about the program. Specifically, you have to verify that any two pieces of code you're worried about actually don't interact, because you no longer have a guarantee that they can't. I think a lot of restrictions are like this.

Edit: To quote a great comment on the article,

> Invariants make software more reliable. Weaker languages have stronger invariants. There’s less stuff to test.

Post reply on HN