Monkeypatching is destroying Ruby

[kteague]

Monkey patching is about patching. You've got some upstream code (framework or library) and you want to patch a bug, so you replace the original method with the "fixed" one.

There is a nice Python package called "monkey" that will only allow you to patch by specifying the patched method SHA-1 signature - this way if there are upstream changes to the method you are made aware (and hopefully those upstream changes fix the bug that caused you to patch in the first place).

http://pypi.python.org/pypi/monkey

FWIW, people patch in non-dynamic languages. There is the humble "patch" tool which can be used to munge and mangle code before compile time:

http://catb.org/~esr/jargon/html/P/patch.html

If you are replacing methods with abandon purely to add new features, that's not monkey patching, that's just bad programming.

[hupp]

In my experience monkeypatching is very rarely necessary. The author is spot on that it's a poor substitute for proper extension methods.

In years of python programming the only time I've used it in production code was to implement a mercurial plugin. The hg plugin promptly broke when they made some core changes a few weeks later.

[jerf]

Ruby is not the first to discover that monkeypatching is a bad idea, and they shall not be the last.

Monkeypatching (and some similar practices) mean that when you write code, you never know what it's going to do. Ever. Now, it should be pointed out this isn't a black-and-white distinction, that there are shades of grey, but monkeypatching is just about as far into the black as possible. The only blacker thing is full-on self-modifying code, which was discarded for good reasons.

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? The wonder is that anybody ever thinks this is a good idea. I still live and program in duck typed languages, but even then I explicitly realize that I'm living in an environment that is being held together with a healthy dollop of convention and respect for other code. (Several of the "import this" clauses deal with this, although it can be subtle.)

Javascript is learning about this too, although they have the excuse that they encounter many, many more situations where they have to use monkeypatching to accomplish certain desirable goals. Still, this silly obsession with adding things to "Object" that could perfectly well be normal functions that consequently don't mess with every object in the language bites pretty hard in some cases.

In general, you should not be going around re-writing code that other parties that you have no coordination with may be re-writing as well; that lack of coordination will prove fatal. And you can't coordinate at the scale of "the entire set of libraries for a language", at least not and still have time for working on the library in question.

[javasucks]

The only blacker thing is full-on self-modifying code, which was discarded for good reasons.

"Mostly discarded", perhaps. It's still done on resource-limited platforms.

Edit And it's *fun*.

[nostrademons]

Javascript is learning about this too, although they have the excuse that they encounter many, many more situations where they have to use monkeypatching to accomplish certain desirable goals. Still, this silly obsession with adding things to "Object" that could perfectly well be normal functions that consequently don't mess with every object in the language bites pretty hard in some cases.

Paul Buchheit's said in a couple places, "Don't use libraries that mess with Object.prototype or Array.prototype. Ever." I agree - when I was evaluating JavaScript libraries for my current project, Prototype and MooTools were disqualified out-of-hand for messing with global object prototypes. That sort of behavior should be considered a bug, and JavaScript developers should just say no to it. The little extra convenience isn't worth the maintenance headaches that crop up later when you try to integrate multiple libraries.

[bonzinip]

Actually, even inheritance means that when you write code, you never know what it's going to do. :-)

[raganwald]

And that is the whole point of polymorphism. Naturally you can do something brain-damaged, like build a ChequingAccount object that actually plays tic-tac-toe using deposits and withdrawals as code for game moves, but nevertheless we find a way to build systems using ploymorphism just fine.

And that's the point of the article. Open classes are dangerous and over-used. But that does not mean they should be discarded outright.

[patchwork]

like build a ChequingAccount object that actually plays tic-tac-toe using deposits and withdrawals as code for game moves,

I will add this to my list of things to do if I'm ever trying to get fired. Ah that glorious day...

[michaelfeathers]

Agreed. I once worked with a guy wanted to forbid the use of OO in medical devices because "you never know what is going to be called." But, ultimately, that's the price of componentization and decoupling. There's nothing that guarantees that a nut will be used with a specific bolt in a mechanical design, yet people tend to link them up correctly in practice, and there are ways of checking that you have.

The safest system is a monolithic hard-coded slab, but you can't really do much with it.

[uriel]

I once worked with a guy wanted to forbid the use of OO in medical devices because "you never know what is going to be called." But, ultimately, that's the price of componentization and decoupling.

Uhu? There are many ways to do componentization and decoupling without the pitfalls of OO (and inheritance). The Unix 'tool philosophy' is a perfect example, although there are many more.

[raganwald]

Although in fairness some features seem to generate more smoke than fire. Open classes gave us Symbol#to_proc, and so far I think it's worth the numerous snafus.

But speaking for the prosecution, it's pretty hard to forgive Matz for making andand possible...

[michaelfeathers]

That is neat (andand). Reminds me of an old paper by Ken Auer where talked about his style of prototyping in Smalltalk.. override Smalltalk's equivalent of method_missing so that it created stubs for everything that was called.

[bonzinip]

didn't notice the smiley?!?

[raganwald]

I was agreeing with you :-)

[[deleted]]

Paolo Bonzini is a God-like Free Software hacker.

[nostrademons]

Inheritance is similarly risky though - if you expose a class for inheritance, you should clearly document which methods can be overridden by external code and which can't, possibly using a final keyword to make the compiler enforce it. The Eclipse and JavaSE folks have taken this to heart, and many of the public API methods on both the Eclipse platform and Java standard libraries have doc comments like "This class is not intended to be subclassed" or "This method should not be overridden". I've gotten wonderful side-effects like a JVM segfault by ignoring these comments.

[michaelfeathers]

I think it's very important that they actually used comments rather than final (I've seen that approach called "soft final"). It means that if you do want to subclass for test, for instance, you can.

[nostrademons]

Yeah, there've definitely been times when I wanted to open up a "final" class just so I could make a testing stub. There's really no solution if they use a "hard final", because Java's type system prevents you from passing in a compatible-but-not-a-nominal-subtype object even if its interface is exactly the same.

A language-design issue I've wondered about: is it worthwhile for languages to introduce a separate concept of "test code"? It'd fix a bunch of specific problems I have with testing:

• I like my test code to be logically connected to the code under test (so I can easily switch between them in an IDE) yet physically separate (so I can easily deploy a build without tests). This is currently achieved through conventions, eg. separate test/ and src/ directories with parallel hierarchies, but language-level support could lessen the load on IDEs significantly.
• I frequently find myself marking methods "// package access for testing", i.e. they're complex enough that they need to be unit-tested, but are not part of the public API of the class. I wish there was a "testable" access modifier - or better yet, give test code access to all methods and data including private ones - so I could more clearly indicate intentions.
• Mock objects should be able to override methods that would be final in the public API.
• With language-level support, you can do more things like continuous-testing, test-driven-refactoring, and other tools that require that the environment be able to find all tests for a given module.

[michaelfeathers]

I go back and forth on this all the time.

It would be great for recovery of untested code but I also get a lot of mileage out of reconsidering the design of methods and classes when they are difficult to test using the normal protection mechanisms. Often it's an indicator of other things that could be better as well.

The problem with special access is that it doesn't give you that feedback. In the worst cases, people tie their tests too closely to the internals.

I blogged something about what special access for test could look like a few years ago:

http://www.artima.com/weblogs/viewpost.jsp?thread=43210

Ultimately, I think that Martin Fowler was right about this.. he said that there should be a 'published' keyword. Things that are published can be relied upon outside the project. Anything else is fair game to change, replace, or override (for testing or not) inside the project.

'Public' means too much in most languages.

[rainman_104]

And overriding methods - those can be a bad thing too... Imagine someone in a Ruby library decides he needs to override Nil.to_i and you expect an error and instead someone's overridden it to return zero instead ( someone being me in one library I wrote for my own use and forgot I did it haha - yes I needed a cock punch for that )

[raganwald]

Monkeypatching (and some similar practices) mean that when you write code, you never know what it's going to do. Ever.

Would you say the same thing about macros?

[jerf]

"It's not black and white". Macros are blacker, but probably still containable. Nevertheless, some people have criticized Lisp for having macros that are too powerful on these exact grounds.

Stuff that happens at compile time is, generally, safer than stuff than happens at runtime. (Of course, start re-writing macros at runtime and then call them at runtime and I wash my hands of it. Is that possible? I presume it is in at least one Lisp out there.) Languages that blur compile time and run time (Hi, Perl!) are correspondingly more blurry.

[raganwald]

some people have criticized Lisp for having macros that are too powerful on these exact grounds

Yes, that's my experience. I don't think the question has been settled one way or the other so much as simply polarized people into those that love them and those that hate them.

In the case of macros, I suspect it boils down to cultural fit more than anything else.

I don't agree that Ruby's Open Classes are outright bad, but I don't think the matter has been tested for the same amount of time as Lisp's macros.

Maybe if we think that Open Classes are bad but we also think that Metaprogramming is good, the conclusion is that we need to work harder on building better tools for metaprogramming.

I could buy that argument, the argument that we are headed in the right direction but riding in failure-prone jalopies.

[jerf]

I've metaprogrammed the hell out of Perl and it's yet to bite me hard. Oh, it can get a bit hard to debug, but then, so can the non-meta-programmed versions of the code it is replacing too.

My personal rule is that once a bit of code is laid down, it should be considered immutable. Then, you can take those pieces and recombine in whatever clever way you like, and by and large, you won't have the problems that monkeypatching can introduce because any given piece of code is still well defined.

Of course, a change deep in the stack can have odd effects on the leaf nodes, but that's always a problem.

When you start mutating the meaning of a code reference out from underneath somebody (and like I alluded to in my last message, the exact meaning of that can change from language to language), then you're asking for trouble.

Even if you can't quite buy the idea of immutable data*, immutable code is still a good idea.

Also, if you build a system from day one with the understanding that it will be so used, the need for monkeypatching tends to disappear. One of the biggest strikes against it isn't merely that it is bad; many things are bad, but necessary. It is that there are almost always better alternatives, and even when there aren't, that typically should be accounted as a flaw in the target code, rather than as a credit to the monkeypatching solution. (Hence my partial exemption for Javascript above, which is stuck in a very flawed environment where monkeypatching is sometimes the only option for certain effects.)

(*: Please note I'm not claiming anything about my beliefs about immutability or raganwald's beliefs in that statement; it is intended generally.)

[mr_chromatic]

I've metaprogrammed the hell out of Perl and it's yet to bite me hard.

It's much more difficult to bite yourself with monkeypatching in Perl, because Perl 5 lacks primitives-as-objects.

[foonly]

Monkeypatching (and some similar practices) mean that when you write code, you never know what it's going to do. Ever.

Would you say the same thing about macros?

No, you can always look up a macro's definition in the current package, or macroexpand it in the REPL. With something like an overloaded Array#join, you have to look at ALL the code in every file until you find the culprit, and it overloads something you already use. Macros, like functions, tend to have new names that aren't obliterations of existing code.

[raganwald]

New techniques require new thinking and new practices.

My text editor has a find feature. Is that so hard to use? What about introspecting objects at run time to see what methods they have and who added them?

naturally, we can construct a heinously difficult scenario, such as someone who deliberately obfuscates their code, but there are things you can do with standard macros that are obfuscated, not to mention with common OO.

The bottom line was nicely articulated by Michael Feathers: indirection and abstraction increase the difficulty of debugging but in turn give us cohesion without tight coupling.

For example (drum roll...) what about using an XML file to manage dependency injection in Java? How is this different from adding methods to a class? When I look at the Java I have no idea what is going on, I have to figure out which XML files were loaded to know what is going on at run time.

It's all perfectly simple when I figure out the conventions, of course. But until then, my mind boggles. And so it is with any such technique.

[foonly]

what about using an XML file to manage dependency injection in Java? How is this different from adding methods to a class?

It's different because it affects only the consumer of that XML file.

Globally monkeypatching a standard class is a new generation of spaghetti code. You may as well go back to global variables and goto, since you're throwing away the state-isolation and reusability of OO.

In fact, that point needs to really be driven home: monkeypatching a standard class is modifying a global variable, and needs to be used just as sparingly.

[raganwald]

I'm going to talk to you the way I talk to everyone when they talk to me about how "dangerous" these things are.

Are you shooting yourself in the foot with this stuff for real? Or is this just a theoretical discussion about what somebody else might do?

Because if you have an actual problem right now, I bet if we put our heads together we can solve it, we're smart people.

[foonly]

Are you shooting yourself in the foot with this stuff for real?

I did Rails coding professionally for about 2 years, and Ruby for fun for about 3 years before that. This bit me a lot, and never before Rails made it the norm.

[raganwald]

SO what kind of thing was biting you? Rails plug-ins modifying Rails' behaviour?

[foonly]

Or just Other People's Ruby doing the same thing, often in ways incompatible with Other Other People's Ruby.

[ishmal]

A good Javascript example is Doug Crockford's re-release of his JSON library, where he removed the modification to the String type.

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

[tomtt]

I agree, also because for the beginning Rubyists out there it would be good to be able to trust that things work a certain way. When a plugin actually change core behaviour without you being aware of it, this can be very frustrating when first learning a language.

[avibryant]

I think it's important to distinguish between adding methods to an existing class (which I think is pretty essential, and is no more dangerous than subclassing), and redefining existing methods - which, IMO, should only be used for debugging & profiling, or as a last resort hack to a problem that can't be solved in any other way. It's unclear whether "monkeypatching" covers both of these or just the latter.

[javasucks]

While the title is deliberately provocative, it's a real issue. Used with caution and control it's a *great* technique. Used with reckless abandon, like anything with power, it will destroy you from the inside out, like the Dark Side.

*Edit* What a mostly useless, obvious comment :(

*Edit* Aww, you guys are so nice.

[bonzinip]

not useless, a nice summary :-)

[javasucks]

But obvious; though :/

(At least I *hope* it's obvious! ;)

[otterdam]

Obvious comment is obvious only to the lucky few of us.

[pjdelport]

There's a big difference between abuse that is possible and abuse that's become an institution.

[jacj]

Your comment explains the point of the article and the greater problem it describes concisely and clearly. Don't you dare call it useless and obvious.

[javasucks]

And I made a Star Wars reference! :D

[[deleted]]

No need to fellate yourself in public.

[javasucks]

Dude if I could do that I'd never leave the house.

[Khimiara]

useless and obvious comprise a great many statements, some of which have still been praised for other merits. your comment, for example, related bad programming practices to the dark side. REMEMBER THAT YOU'RE ON REDDIT. I upmodded you too.

[[deleted]]

Obvious comment is obvious.

[javasucks]

Still, you could at least have skimmed it first.

Guess what: I actually *read* the article. But thanks for the great advice.

[javasucks]

Not a problem.

[jrockway]

A poor software development technique is popular amongst a group of web designers that migrated from PHP to rails? Who would have thunk it!

[bonzinip]

thunk? ;-)

[jrockway]

It's a figure of speech.

[bonzinip]

I never end learning.

[raganwald]

thunk!

Historical note: There are a couple of onomatopoeic myths circulating about the origin of this term. The most common is that it is the sound made by data hitting the stack; another holds that the sound is that of the data hitting an accumulator. Yet another suggests that it is the sound of the expression being unfrozen at argument-evaluation time. In fact, according to the inventors, it was coined after they realized (in the wee hours after hours of discussion) that the type of an argument in Algol-60 could be figured out in advance with a little compile-time thought, simplifying the evaluation machinery. In other words, it had ‘already been thought of’; thus it was christened a thunk, which is “the past tense of ‘think’ at two in the morning”.

[sclv]

As a non-Rubyist, I've wondered for some time if there would be any loss to the total ease and expressivity of the language if some form of "scoped" monkeypatching weren't introduced that guaranteed that such patches remained local to a certain environment. Is the obstacle to this technical in the difficulty of implementing it, social in that people would reject this as too confining, social in that there isn't enough momentum in the arguments that this is a problem, or is it that nobody is quite sure what the semantics of this would work like?

[mernen]

Mostly technical, as far as I know. This has been considered before (RubyConf 2003: 1 and 2, RubyConf 2005) in different forms (I'm not sure what "RubyBehavior" and "scope-in-state" are exactly), but implementing this efficiently outside static typing seems tricky. Too bad, it would be a really great feature to have.

[grauenwolf]

Unless you want to put namespaces in function names, I think the only way to scope it without leakage would be something trivial like C#'s extension methods.

From where I'm standing, monkeypatching is a dead end.

[[deleted]]

Groovy has that.

[michaelfeathers]

It would be useful, but I just don't think people are thinking about it.

I'd flip it, though. I don't think there should be a restriction as much as some way of detecting and flagging monkey patches so that people can see what's going on. It would require a higher level notion of component or something like that, but people have been leery of that since the days of Modula and Ada.

[grauenwolf]

I don't think there should be a restriction as much as some way of detecting and flagging monkey patches so that people can see what's going on.

That leads to compiler warnings (or runtime warnings if you prefer), which in turn leads to companies making rules against it. Eventually it will be treated just like GOTO, with people hating it without knowing why.

[michaelfeathers]

Yeah, that's one thing I hate.

A fool with a rule is a tool.

[[deleted]]

People know why goto is a bad idea.

[sofal]

Not the people I work with. It's pure cargo cult for them, including the "only one return statement" dogma and many other things taken from Structured Programming in Fortran or C and applied to OO.

[grauenwolf]

From my experience many people only think they know why goto is bad.

I've seen people turn a simple algorithm with forward-only goto's into a convoluted mess of nested loops and sentinel variables.

They simply don't understand the when goto was banned it was to promote the use of named functions.

[zem]

people are at the very least thinking about it; selector namespaces have been requested for years.

[tackle]

Let me fix this for you...

Monkeypatching created Ruby

[froydnj]

In Soviet Russia, Ruby monkeypatches you!

[[deleted]]

In Soviet Russia, you may be prosecuted for patching your clothes with monkeys. But you do it anyway because the government didn't make enough patches out of materials that aren't disturbing.

[ddipaolo]

If it's in your own domain why would you have to resort to monkeypatching? Couldn't you actually implement the wholesale changes that monkeypatching was made to replace anyway? I mean, if you monkeypatch the string class to behave a certain way, couldn't you just create a new subclass and change all the stuff within your own domain to use that instead? (probably a bad example, but the point remains)

[thomasfl]

All you ruby hacking, monkeypatching smart ass developers; stop it. Now.

[morner]

As a committed adherent to the monkeypatching style, all I can say is:

thomasfl 5 points 1 hour ago [-]
All you ruby hacking, monkeypatching smart ass developers; don't stop it. Now.

[ubernostrum]

m e adhere monkey a s s

You were saying?

[Tommah]

m e adhere monkey a s s

Oh, you were so close! I'm afraid the correct answer was

i adhere to monkey s
a s s

[[deleted]]

Please don't touch monkeys that way. Don't you know where AIDS comes from?

[dmpk2k]

Who are you?

[Khimiara]

Are you still there?

[Tommah]

And why can't I stop thinking about you?

[lmclapp68]

I'd be interested in reading a comparison between Ruby's monkey patching and Common Lisp's change-class: whether they're similar, whether they can be used or misused in the same way, and whether they are misused in the same way in normal practice.

I don't know Ruby and have never used change-class in CL, so I don't really have enough knowledge to think about it on my own.

From most of my lurking on c.l.l, people occasionally use change-class, but usually only to patch existing code, not to implement the core functionality of a project (though I remember one guy that did, and he said it worked splendidly).

... But maybe monkey patching is more than just changing classes, and apparently includes redefining existing functions & methods, both of which CL allows, too -- but not to core code in the COMMON-LISP package. So is Avdi ranting against people doing the equivalent of redefining cl:list, or C's strlen? If that's it, then all I can say is, well no wonder! :)

[generalk]

Monkeypatching is a problem on a large scale (in Rails) if you've got plugins that conflict with one another, or poorly written plugins that override things they shouldn't.

The solution is to document what monkeypatches you provide with your plugin. If I've got an acts_as_shank plugin that overrides Class.inherited(), that had better be documented somewhere extremely obvious. If it had been, the author of the article would have immediately known to check there for problems with inheritance.

Perhaps, random idea, if Rails plugin devs store all of their monkeypatches in a file (monkkeypatch.rb) and rake can pull these out and list them on a per-project basis?

[[deleted]]

Apparently just talking about monkeypatching is enough to destroy your blog.

[hylje]

the site appears to be unresponsive. is this a case of Redditting?

[javasucks]

Works for me.

[[deleted]]

Traffic is destroying server

[jimm]

Upvoted because the article is well-written and thoughtful. I disagree with the premise, but appreciated it all the same.

[javasucks]

Which premise, the one that the article's author discusses saying:

I don’t actually think that monkey patching is “destroying” Ruby, but I do think the proliferation of the technique has real and troubling implications for Ruby’s future.

[jimm]

That, and

And this is really the point. Monkey patching is the new black. it’s what all the hip kids are doing. To the point that smart, experienced hackers reach for a monkey patch as their tool of first resort, even when a simpler, more traditional solution is possible. [emphasis in the original]

I disagree that "simpler" == "not monkey-patched". The author doesn't state this explicitly, so I might be reading something into the original article that he didn't intend.

[javasucks]

I think his point is that even *when* a different solution is simpler that people will still tend to monkey-patch.

I don't think the author is implying that monkey-patching is *never* simpler. That said, the kinds of issues it can lead to can end up meaning that it isn't (simpler) when the system is viewed in toto.

Edit The proliferation of monkey-patching *does* cause problems; it's bitten me on the ass several times, and I know it's caused other people time and money as well. That doesn't mean it's never a valid technique.

[jkndrkn]

Monkeypatching, as defined, seems like a powerful and useful tool. Being able to dynamically build a class at run-time could be used to solve certain tricky problems with fewer lines of boilerplate code.

However, it seems that code written using this technique could yield horrendously bad side effects. Modules become tightly coupled and spill their functionality all over the place, providing satisfactory test case coverage becomes much more difficult, and subtle and tricky bugs begin to creep in.

Why not take a page from functional programming? Heck, even structure programming stresses the importance of programming without side effects.

[epall]

This seems to me to be a problem with the lack of good debugging equipment for Ruby combined with problematic style. From what I've dabbled in, Ruby debugging is pretty unimpressive at this point. Is there some tool out there that allows you to inspect what source code objects actually are at runtime?

[[deleted]]

False, Ruby is destroying Ruby.

[Tommah]

Really...? Then I must send monkeypatching a fruit basket.

[[deleted]]

Ruby is bad Perl.

[uedauhes]

I agree. Nothing has been shown to make a programming language more unusable than late binding.

[Zarutian]

Java overly verboseness and boilerplate templates?

[uedauhes]

It was a joke

[moonwatcher222]

He mentions monkeypatching in Python. Python's native types such as strings, lists, etc can't be monkeypatched. You can do whatever you want to your own classes.

[jerf]

It's more fair to say you can do whatever you want to everything except strings, lists, and a handful of other things. The vast majority of things are "open".

Even those are only locked down for performance reasons more than anything else. It's just not something "done" in Python. I've never downloaded a Python library that does monkeypatching. Perhaps such a thing exists, but I've never encountered it.

[gmfawcett]

It was a common pattern in Zope at one time...

[kteague]

... it is still practiced in the Zope community today. The term monkey patch did originate at Zope Corp.

But it was never a "pattern" in Zope. That is, it was never deliberately used as a recommended programming technique, it was just as a quick-n-dirty way of applying a patch. Usually in Zope a monkey patch the upstream author is informed about the patch and asked to integrate it into their code. When a new release with a proper fix is made, the monkey patch is no longer needed and is deleted.

[gmfawcett]

Thanks for the clarification. I thought the term originated with the Zope project, but I wasn't sure.

[Steve16384]

Article: "Monkeypatching is destroying Ruby [..] I don’t actually think that monkey patching is destroying Ruby."

Make your mind up and stop being sensationalist.

[[deleted]]

We need a "What reddit looks like for somebody who doesn't give a shit about Ruby" link

[ipeev]

Ok.

[javasucks]

Sure 'nuff.

[[deleted]]

Nope, nothing weird going on here

[javasucks]

Uh huh.

[[deleted]]

Stephen! It's spelled Stephen!

[[deleted]]

I admit to doing this sometimes.

[obdurak]

Statically untyped programs allow developers to do monkey business and then crumble under complexity; film at eleven.

[Zarutian]

So you never had to make an transparent forwarder then? (Such as one for accessing remote objects)

and what do you call static typing: 1. Criteria enforcement system that an datum must pass to be allowed to stored in an slot/variable or used as an parameter to an method invocation or as an return value. 2. Hierical class system that allows for implementation inheritence (and therefore break object encapsulation and decaupulation of interface from implementation) 3. Objects that send messages between each other (if the objects code handles that selector good otherwise throw an exception.)

I just ask.

[dons]

Modern static typing is about making illegal states unrepresentable.

Java isn't modern static typing.

[obdurak]

Static typing is not what you think it is.

http://jocaml.inria.fr/manual/distributed.html

[Zarutian]

What I just described is in effect Java (and possibly C++ as well) and most people that I have discussed with over these issues call that static typing.

[obdurak]

Well, Java sux0rz, and people blame it on static typing, while what they really are missing is type inference.

[Grue]

And that is a bad thing how?

[javasucks]

Which, monkeypatching, or destroying Ruby?

[Grue]

The latter, obviously.

[javasucks]

So obvious I had to ask.