3 ms·

Monkeypatching is Destroying Ruby

15 points by muriithi 19y ago

xirium 19y 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 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&q=engedu http://video.google.com/videoplay?docid=8566923311315412414&... ).
- avdi 19y 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.
  - xirium 19y 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.
    - xirium 19y ago
      I've read a lot of ELisp code, and I have very rarely seen the equivalent of Ruby-style monkey patching. Even the advice mechanism, an AOP-like feature which enables functions to be dynamically wrapped and chained, somewhat like Rails' alias_method_chain, is used sparingly. Instead, every mature Emacs extension exposes a plethora of "hooks", extension points that other packages can attach their own handlers to. Other packages add their handlers to these hooks, and to hooks that the core Emacs code provides, and thus they cooperate largely without collisions. -- http://gilesbowkett.blogspot.com/2008/02/never-complain-only-ever-code.html http://gilesbowkett.blogspot.com/2008/02/never-complain-only...
mechanical_fish 19y 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 19y 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 19y ago
  Interesting, when I looked at this comment yesterday it was at -1. Now it's at 10.
timr 19y 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/

15 points by muriithi 19y 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 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&q=engedu http://video.google.com/videoplay?docid=8566923311315412414&... ).

avdi 19y 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.
- xirium 19y 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.
  - xirium 19y ago
    I've read a lot of ELisp code, and I have very rarely seen the equivalent of Ruby-style monkey patching. Even the advice mechanism, an AOP-like feature which enables functions to be dynamically wrapped and chained, somewhat like Rails' alias_method_chain, is used sparingly. Instead, every mature Emacs extension exposes a plethora of "hooks", extension points that other packages can attach their own handlers to. Other packages add their handlers to these hooks, and to hooks that the core Emacs code provides, and thus they cooperate largely without collisions. -- http://gilesbowkett.blogspot.com/2008/02/never-complain-only-ever-code.html http://gilesbowkett.blogspot.com/2008/02/never-complain-only...

mechanical_fish 19y 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 19y 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 19y ago
Interesting, when I looked at this comment yesterday it was at -1. Now it's at 10.

timr 19y 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/