From: James Tucker Date: 2008-02-25T02:27:12+09:00 Subject: Re: Monkeypatching is Destroying Ruby I can't agree with this, there's too much going on to really make such a widely aimed statement. Monkey patching may be destroying a lot of developers, but how can most of 'the community' who, (myself included), have not been involved with ruby for sufficient years to be entirely confident on which patterns will be bad and which will be good, for a given situation. With the amount I have learned about ruby over the past couple of years, and the drastic swings in code quality, I can see how these things happen too. I went through stages of enjoying meta based solutions, right back to OO again, learning the simultaneous destruction and power of various techniques. I've been through stages of writing code that very few people can read, and those that can don't want to, right back to making code that non- programmers can read clearly. Ruby makes all sides easy, what you choose is a combination of culture, purpose, desire and habit. Many young ruby developers have a desire to be 'clever', and this often starts to disappear after some experience (in my experience). Hail simplicity, it will be good for all of us, but as for monkey patching destroying ruby, I'm not so sure. Trying to stay a little away from the pattern discussion (as I hate the term, I think it leads to mis(/over)use). I would make the observation that some pieces of software in use in some really successful ruby projects (one that really screams out in my head, as rails was mentioned, is evented_mongrel, by Kirk Haines), is supplied entirely as a monkey patch along with the swiftiply package. The important thing is for developers to realize the impact of the code they write, and as most experienced developers can tell you, this takes wisdom that is gained largely through experience, and one can never expect to catch everything in every scenario. The 'pattern' (if you like) of monkey patching is not one which is easy to maintain, by it's nature it can be very coupled with any underlying implementation, and often requires shortcuts to be taken (some (maybe most) would say it is a shortcut by it's very nature). It is however, a fantastic prototyping tool. It is incredible when used at the final application development stage when you really just need a behavior to change on an underlying framework or api. Clearly there are better and worse ways to go about these things, and as always tests and documentation really help (as by these procedures, if there is a better way, you will often find it producing those). I think for frameworks under ruby, there are possibly some 'patterns' which are good to adhere to, and they are being discussed continually all over the place. Mostly they boil down to good (clean, maybe so far as to say 'pure') OO patterns, for which ruby provides some real convenience. $0.02 On 23 Feb 2008, at 21:07, Avdi Grimm wrote: > Hi folks, > > I wrote a blog post with the intentionally provocative title above, > which can be found here: > > http://avdi.org/devblog/?p=18 > > While the title is a bit of deliberate hyperbole, I am genuinely > troubled about the popularization of monkey patching in the Ruby > community. I explain my reasons more thoroughly in the post, but > here's a synopsis: > > Monkeypatching has become the hip thing to do in the > Ruby and (especially?) Rails communities, and it has > reached the point where experienced programmers are > turning to it as the tool of first resort *even* when there > is a simpler, more traditional solution available. I > suggest that it's time for Ruby hackers to start setting a > better example. > > My hope with this post is to start a conversation about fostering > robust software extension mechanisms in the Ruby ecosystem. I welcome > any comments, both here and on the blog. > > -- > Avdi > > P.S. Before anyone accuses me of it, yes, this is a kind of > self-promotion. But I really do want to start a conversation about > this, and no one reads my blog. >