From: Avdi Grimm Date: 2008-02-24T07:04:55+09:00 Subject: Re: Monkeypatching is Destroying Ruby On Sat, Feb 23, 2008 at 4:38 PM, Gregory Seidman wrote: > I read the post. I think it is both futile and wrongheaded. Futile, because > I don't think it will change anyone's opinion. Wrongheaded, because I think > it's a filtering problem rather than an approach problem. Thanks for reading it! I appreciate your feedback. > are crap. How do you tell the crap from the good? That's a filtering > problem. Trying to get people to only release good code is utterly futile. I want to make it clear that I never called for only releasing good code, or for some kind of control over what kind of code is released. 80% of everything will always be crap; but there's still value in setting a good example. > There's an argument, usually in the context of test-driven development, for > doing the simplest thing that works. Well, you say, it doesn't work. No, it > *no longer* works for your purposes. That's when you need to revisit it. If > a piece of code implementing functionality you need is causing problems, > you need to either fix it or find/build a new implementation of that > functionality. I think there's a misunderstanding here - I used the example I did because it was a case where the initial solution was *not* the simplest thing that could possibly work. I obviously cannot speak for Dan's thought process, but to me it appeared an example of having gotten into the habit of always reaching for the monkey wrench (if you'll excuse the pun) first, even when it's not the most pragmatic tool. Whether or not this was the case with UnitRecord, it is definitely an attitude I've seen more and more lately. It's this habit that I'm trying to combat, because I think a lot of times monkey patching not only hurts productivity in the long term, it hurts it in the short term too. Monkey patching is *not* always the shortest distance between two points. It's tricky and prone to subtle bugs. I do not agree that monkey patching is usually the quick & dirty solution - often it's the slow & dirty solution. Unfortunately, along with the assumption that monkey patching is the easiest way to get things done comes the assumption that if anyone wants to extend your code they can always monkey patch, so there's no point providing extension points. Again, thanks for the alternate point of view. -- Avdi