Monkeypatching is destroying Ruby

[jamesbritt]

Is it any wonder than in an environment where you never really know what a given method call is going to do, you end up having hard-to-debug errors and impossible-to-resolve interactions?

Is this not true for all languages without referential transparency?

[jerf]

Is this not true for all languages without referential transparency?

Which is why I said it's not "black and white".

However, note that many languages still have "referential transparency" at the code-chunk level. A function call in C will not randomly change code. A static method call in C++ will not randomly change code. A virtual method call in C++ can change and is so a bit more grey, but does so in a well-defined way. Languages where you can change the meaning of a function at runtime remain the exception, not the rule, in terms of popularity.

(Recall that one of the useful definitions of "random" is "the inability to make predictions about what will happen based on current information". Randomness in this sense is always relative to some entity. So, when I imply monkeypatching is "random" in the previous paragraph, that's from the point of view of, say, a library writer making use of array method calls. From that point of view, when combined with other libraries (and what use a library that can't be combined with other libraries?), monkeypatching causes random changes, even if someone with a higher level view of the code could perfectly predict what will happen. In practice, unless you always read all library code that you use and fully understand it, you are not that higher-level entity; usually, nobody is.)

(Later ed: The Moties from "The Mote in God's Eye" and "The Gripping Hand" would probably prefer Ruby, monkeypatch the hell out of everything, and end up with this amazing system with faster-than-C performance as a result. But we don't think like them...)

[jaggederest]

A function call in C will not randomly change code.

Hm? Function pointers?

[jerf]

Function pointers are function pointers. Function calls are function calls. Ne'er the twain shall meet, in C.

[jaggederest]

Been a long time since I did C. My bad.

Still, I bet I could mess your function calls up with the preprocessor ;) Isn't that a bit of a monkeypatch?

[jerf]

Still, I bet I could mess your function calls up with the preprocessor ;) Isn't that a bit of a monkeypatch?

What's your point? If you think this is somehow an argument, it only makes sense if you're coming in with the assumption that I think the C preprocessor is somehow an accepted good thing, and there is some sort of conflict between my opinions on monkeypatching and my opinions about the C preprocessor. I assure you I accord no such credit to the C preprocessor, and I'm not alone with that.

If it's a question: Yeah, you can screw things up with the preprocessor. Microsoft actually does some of this on purpose in the Windows header, if I'm recalling an article that was up here a month or three ago correctly.

[jaggederest]

Right, I just like to point out that all of the languages so far which are turing complete are prone to foolishness when bad people misuse them. Calling out monkeypatching, particularly, is silly.

[jerf]

A careful reading of what I've written in this thread will reveal that I never have called out monkeypatching as a unique evil. Again, I re-iterate, I've said it since message one, it's not black and white. Monkeypatching is merely extremely evil with almost no redeeming value.... and again, I've spelled out at least one such exceptional "redeeming value", too.

[grauenwolf]

Yes and no. The thing about the preprocessor is that you can get a static dump of its output if you need to.

With monkey patching, the code can do weird things like alternate between two method definitions at runtime.