The Case Against Monkey Patching | Hacker News Reader

The Case Against Monkey Patching

shopify.engineering

40 pointsyarapavan19 comments

I’m not meaning to make a case for monkey patching per se, but it’s interesting that the major points in this article are actually just points against forking and patching open source code at all.

The Stallman-era idea of taking possession of your own copy of open source code so that you can do with you want with it, is now being argued to be too dangerous for you.

You should just trust the upstream team, just like you would with proprietary software, and if you reaaally need something custom, you should let them take a look at your idea in a PR and they’ll decide if it’s a good idea that can be merged when they’re ready to schedule it in.

When you look at the security risks and developer talent at play today, you can understand why this argument makes some sense. But if you’ve watched or been part of the of the Open Source Revolution, you kinda have to laugh at the irony.

Could you give an example? Most of the arguments in the post seemed to be focused on long-term maintenance. It does put a lot of faith in the upstream allowing contributions and making good decisions, especially when viewed through the lens of Ruby/Rails a belief that upstream continues to exist. To me though some of the arguments like submitting fixes is actually encouraging the reader to fork and make their own changes as opposed to using dynamic modification to behavior.

I don't see any conflict - I don't think Stallman has anything against sharing improvements and developing together. If anything the old-school FSF development model was more centralised (see The Cathedral and The Bazaar). If you have access to the source you can understand it and fix bugs in it; that's true whether you apply them locally or submit them upstream.

In fact, RMS advises (heh) against advising core emacs functions in elisp; which is more or less monkeypatching.

https://www.emacswiki.org/emacs/AdviceVsHooks

He specifically said that about code in Emacs itself, and only insane people would disagree with that position when you can just change the original function.

IMO, and I suspect RMS would agree: defadvice shouldn't be used in code you distribute to others, because multiple pieces of advice can conflict, and the code defining the advice doesn't control which advice is loaded first. It is still a valuable tool for usage in personal configuration and for prototyping.

Maintenance costs as time goes on can be expensive.. at least relative to 0 maintenance cost. With a lean team it feels bad.

I have heard this exact sort of thing frequently and it’s always from upstream devs who literally want to decide exactly how downstream do everything and refuse to accept reasonable changes from people using their stuff in the field who just need it to work slightly differently from the upstream version.

I don’t use Ruby, but I have had to monkeypatch a lot in Java and literally every time I would have preferred not to, but did it because I had to.

I once had a fun conversation with a head of product for some software once where he said a monkeypatch is ok for a spike when you’re testing something but you should never monkeypatch in production and I explained I had 14 monkeypatches to his product currently in production and you couldn’t even log in with ssl to his product without monkeypatching out some parts of the SSL cert verification code because the cert verification wouldn’t work with certs issued by an enterprise CA (rather than a trusted root CA).

In all of these cases these were patches that had been submitted upstream that I didn’t want to have to maintain but had been rejected by upstream because my use case wasn’t what the dev thought the general use case was. That’s fine btw and exactly why monkeypatching is useful.

> refuse to accept reasonable changes from people using their stuff in the field who just need it to work slightly differently from the upstream version.

On the other hand reasonableness is in the eye of the beholder.

As both user and victim of monkeypatches, i’d rather nobody had to but there’s not always an agreement to be found (or feasible at all).

On that point I like Cargo’s support for local versions / forks of dependencies, it provides a cleaner and less fraught support for patching your upstream (whether you ultimately fork or not).

The fact this is even a discussion is why I would never use Rails again. I suffered a decade of Ruby and never again.

Typescript is my language of choice because of its full stack flexibility and amazing tooling support because of typing. If you think typing systems are too confusing you're definitely not qualified to write monkey patches in an untyped language. Typing reduces minor bug iterations by 90%+, major bugs immensely, and ultimate development resources by 90%+.

One person can maintain a huge Typescript app with just basic tests. You need a teams of people to maintain 50x the number of tests and fix obscure bugs with any Ruby app.

I'm not even sure an AI could refactor a Ruby app properly, but Typescript any human can.

If my time at Facebook has taught me anything, it's that using an untyped language is pennywise and pound foolish. Whatever time you save in the short term, you're going to pay back 100x in the long term.

FB devs wrote millions of lines of PHP/Hack code when it was untyped, and then it gradually became more and more typed, and they had to keep modifying the entire codebase with various elaborate schemes so that it sort of complies with increasingly strict type checking. A lot of that was inserting compiler directives to say "ignore type errors on the next line." That built up tech debt which eventually had to be dealt with, and doing that is soooo much more difficult than writing typed code in the first place.

You say that but when actually measured typing triples both development time and bug count.

You say that.

Is monkey patching better than copying and modifying the entire dependency? I see tradeoffs both ways.

At the end of the day, the job needs to get done. Sometimes this involves modifying existing things for a particular purpose.

The JavaScript ecosystem has pretty good support for patching a dependency without copy+pasting it.

https://github.com/ds300/patch-package#set-up

I think it’s a royal pain in the butt to be cleaning up the accumulated cruft of the monkey patches other people have added to your long-lived and massive Rails app. I’ve done it, and it sucks.

But it’s a wonderful, powerful tool to have in the toolbox, when used sparingly.

I wonder how much of the pain of monkey patching could be partially explained through the way that large companies maintain (or don’t maintain) their codebases? In my experience code is often hard to maintain because of a lack of continuity, context, and support from an employer to actually do the maintenance. In that world, monkey patching is an extra-special kind of hell.

I wonder sometimes if we might all feel less strongly about monkey patching if we had more time to care for the code we write.

Most of their criticisms boil down to "if this is better as an upstream patch then do that please." Every patch I've written (not in Ruby) has been to add functionality upstream definitely would not care about or want to maintain (relegated to application entrypoints to aid maintainability on my end). Are other use cases common in Ruby?

Patch what you need, that's literally the point of the language feature.

Just because you can, doesn't mean you should.

> We’re going to use patching the Rails framework as the main example because…

…Rails is really a product of its time and no-one should be using it almost 20 years after that.

Reply on news.ycombinator.com