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