Monkeypatching is Destroying Ruby

http://avdi.org/devblog/2008/02/23/why-monkeypatching-is-destroying-ruby/

by muriithi • 18 years ago

15 8 18 years ago

xirium3• 18 years ago

From the article: Emacs Lisp, the language it is written in, is every bit as dynamic as Ruby.

Warning! Author thinks in Blub ( http://www.paulgraham.com/avg.html ).

More seriously, Ruby's apparent class patching combinatorial explosion of bugs makes a very good case for aspect oriented programming ( http://video.google.com/videoplay?docid=8566923311315412414&... ).

avdi• 18 years ago

As a committedly multilingual prgrammer, I'm not sure what you mean by saying I think in Blub (and yes, I'm familiar with that article). Is it because I failed to note that Lisp is in many ways far more powerful than Ruby?

I don't think it makes a particularly good case for AOP myself. AOP is just another, slightly more structured, form of the same thing - a structured COME FROM (see INTERCAL), if you will. The ability to globally append to or modify arbitrary functions in existing code is no substitute for a) limited extension within the scope where the extension is actually used and b) actually coding classes with well-documented extension points, whether Emacs-style "hooks" or some other mechanism.

xirium3• 18 years ago

I was joking about Blub. In the context, it would have been extremely unreasonable to describe the merits of Ruby and Lisp in more detail.

Regarding AOP, when I saw the video, I thought "OMG! Someone invented OO COME FROM by matching stackframes!". Indeed, a question in the video subsequently alluded to a stack implementation.

Anyhow, although it is possible to write an entire application in aspects, it is likely that the worthwhile threshold for doing anything in AOP is larger than the threshold for doing anything in OO. In trivial cases of OO and AOP the execution overhead is minimal. Furthermore, there's opportunity to reduce overhead when you've got a bytecode implementation. I'll give an example using testing and asserts.

If we had a bytecode implementation which supported aspects and we loaded a test harness, the test harness aspects could effectively add asserts throughtout the code. If you don't load the test harness then the asserts aren't formed. Languages like Ruby are ideal in this situation because the bytecode can be devised such that trivial and non-trivial cases can be easily added into already compiled bytecode. This means that you've got hooks everywhere without forethought and with minimal overhead. Planning ahead remains a better option but its nice to have a fall-through case which scales.

mechanical_fish• 18 years ago

Writing tip: When the first paragraph of your essay is an extensive apology for the poorly worded title... your title is poorly worded.

If you're gonna linkbait do it like you mean it. Otherwise the effect is that of Darth Vader saying "I beg your pardon".

h34t• 18 years ago

He used a dramatic title to bring attention to an issue which he believes (1) is important and (2) can only be fixed if a lot of people become aware of it. He explains this clearly, honestly, and without apology.

pchristensen• 18 years ago

Interesting, when I looked at this comment yesterday it was at -1. Now it's at 10.

timr• 18 years ago

Absolutely agreed. So much of what makes Rails "easier" than other frameworks is based on a disregard for established best-practices -- particularly with regard to encapsulation and data-hiding. Monkey-patching is but one example.

Another is rails' attitude toward private data. Every DB field on an ActiveRecord object is world-writable, whether you like it or not. That's fine for prototyping, and works adequately well when you have a small team of developers who never get rushed or sloppy, but is a terrible idea for long-term code stability.

Now, you can hack around this and make attributes private-ish, but it's not easy, and as best as I can tell, nobody in the rails community actually does it on a regular basis. This blows my mind. Yes, sometimes you want the ability to rapidly hack up a prototype, but if your framework precludes the ability to turn that prototype into a robust model with minimal effort, then I think your framework is flawed.

/flame-proof suit on/

Monkeypatching is Destroying Ruby

Related Stories