Dynamic Weenies are crazy !

I tried to understand the monkey-patch concept. I drove into that gem:

http://blog.nicksieger.com/articles/2008/03/14/monkey-patching-is-part-of-the-diy-culture

Excerpts (bold text is by my own decision) :

So, it took me a while before it occurred to me that something in my project might be overriding make_tmpname. But even after I found it, notified MenTaLguY, and he fixed it, it still left me wondering: who’s in the wrong here? Akira-san, for not making a better way to hook into make_tmpname, Rick for monkey-patching it, or MenTaLguY for changing the method arity in his rewrite? I can’t really point the blame at any of them.

There are certainly more egregious and offensive monkey-patches than this example (and I include myself in that camp). In any case though, I could live with just about any monkey-patch if I had better debugging tools. For example, it would be great if you could ask Ruby to track and retain references to all methods, including those that get replaced, along with the source locations where each was defined. Another possibility might be a before_method_added hook that could let you track method replacements as they’re about to happen (and maybe even veto method redefinitions!).

Yeah, and why not veto the veto, and allowing some other code to veto that also :-)

You can't point the blame? The blame is to consider monkey patching a valid programming practice! If you want to be able to veto method definition, or need debugging methods to track the changes, maybe there is something wrong with the concept...

Think of it: he even considers that the guy who changed a private method could be the one to blame :-)

Incredible! Everyone with common sense agrees that statefulness is evil, and these guys try to add yet more state to try to control the state. And we have to trust them to build secure software?

We will never agree

From another post :

In Ruby I can write this:

10.times { i puts i }

But in C# I have to write this:

for (int i = 0; i < 10; i++)
{
Console.Write (i);
}

Which do you find more beautiful? :-)

Actually, I strongly prefer the C# version. Not because it is more beautiful, but because it is more descriptive. How do I know whether "10.times" will count from 0 to 9 or from 1 to 10? Or from 412 to 421? How do I know that it will count upwards ? Or backwards? Or randomly?

And anyway...

10.Times (i => Console.Write(i) )

:-)))

Statefulness considered harmful... again :-)

Serious programmers keep telling you ... again and again. Dynamic weenies keep not wanting to hear ... again and again.

http://kurt.karmalab.org/articles/2008/04/24/monkey-patching-core-classes-bad

"the first thing that happened was that 20 completely unrelated specs broke"


---


"This, in turn, snuck into our codebase in all sorts of little unexpected places."

Having the possibility to modify any behaviour of any object at runtime (monkey patching) is the silliest idea since trying to manufacture nitroglycerin in a rollercoaster. Whether it is a core class or not is irrelevant, it is still a stupid idea. Modifying a method in a class is the same as the nice Cobol feature ALTER PARAGRAPH TO PROCEED TO.

Thank you again for these few minutes of irrepressible laugh :-)

From the master himself

I know it's a long time ago, but in an interview with Bill Venners, on November 17, 2003, the master Yukihiro Matsumoto himself said:

So for day-to-day programs that aren't not as serious as enterprise systems, you don't have to be as robust. It's not worth the cost of declaring types, for example.

So he agrees: declaring types has a cost, but it adds robustness.

http://www.artima.com/intv/tuesday3.html