

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

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

------
timr
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_ /

------
xirium
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&...](http://video.google.com/videoplay?docid=8566923311315412414&q=engedu)
).

~~~
avdi
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
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
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...](http://gilesbowkett.blogspot.com/2008/02/never-complain-only-ever-
code.html)

