My favorite ActiveSupport monkey patching is on number classes. Things like 2.weeks.from_now are just too useful to scorn monkey patching on some programming ideological reasons.

I wish every language had open classes for this reason. It makes ruby such a joy to write in. Something like Kotlin's class extensions might be a happier middle ground for many languages though, since that way you only get what you pulled in, in any given file.

Yes, of course you can do horrific things with it. But the ruby community has largely been absolutely stellar about not doing that - most keep insanities tightly bounded, where they can be used to make pleasant and error-resistant APIs. And even when they're not (which is usually self-inflicted by internal code), the language is flexible enough to let you unfuck just about any fuckery that you run across, if needed.

I'd argue the opposite. Most ruby codebases are infected with monkey patches, extracting libraries now depends on activesupport being used, forcing the dependency

Activesupport is hugely widespread, yeah. It's a bit unfortunate since it provides so much, and it's rare that all (or even most) of it is used.

But beyond that though, the vast majority of issues I've seen with monkey patching has been stuff that was created in the project/company that's experiencing the problems. Libraries are generally very good about how they monkeypatch (because doing it wrong with hundreds of using-projects VERY quickly runs into problems), but those ad-hoc internal monkeypatches are routinely done by people who don't fully understand what they're doing, or take shortcuts. Those can have latent bugs linger for a very long time, and yeah - they can be nasty to unravel.

> Activesupport is hugely widespread, yeah. It's a bit unfortunate since it provides so much

Even this is becoming less and less necessary as more of the commonly-used syntactic sugar gets pulled into Ruby core.

Open classes are against SOLID principles (O stands for - classes should be extendable, but not modifiable). So, a big no in some circuits. Aside from open classes, ruby also have instance_eval and class_eval taking to violating that principle to whole new level.

Funny thing, that construction is actually pretty easy to achieve in buttoned-up and statically typed C# with extension methods:

        static TimeSpan Weeks(this System.Int32 n)
        {
            return new TimeSpan(n*7, 0, 0, 0);
        }

        static DateTime FromNow(this TimeSpan dt)
        {
            return DateTime.Now.Add(dt);
        }

        static void Main(string[] args)
        {
            Console.WriteLine(2.Weeks().FromNow());
        }

Not bad! I also feel like it’s worth mentioning that in rust you can extend primitive types with traits. I’ve done that to add some bit-munging helpers while working on a toy Game Boy emulator to make it easier to deal with 16- and 8-bit register values like (8, 8).join() and (l, h) = 16.split().

I'm impressed actually.

Oh god no. If you want to parse strings, parse strings. I avoid Ruby like the plague (after about 2 years where it was my primary language) because of this kind of clever magic spaghetti that subtly breaks in all sorts of cases.

That's Rails not Ruby actually. And it never bothered me once but to each his own...

Weeks(2).from_now

I don't understand how monkey patching is beneficial beyond personal preference.

The entire Ruby ethos and surrounding APIs are basically all a result of a particular set of personal preferences. One of the core values of Ruby is programmer happiness. That’s obviously qualitative and varies from person to person. That said, this kind of pattern is extremely _Ruby_ and if you like it, you like it. I love writing Ruby code because of this kind of attention to making code almost like prose. However, I’ve also worked on a lot of terrible Ruby projects that were a mess of metaprogramming and clever dynamic language abuse, so it’s hard to mount a rigorous defense.

My first experience with Ruby was writing rspec tests and chef recipes, and I can't say I was very happy when I had to debug that code. It's given me a deep aversion towards any Ruby DSL that still persist. I will work with Ruby if I have to, but I am not happy about it.

The way Ruby does metaprogramming makes debugging extremely frustrating because your stacktraces will contain references to methods that exist nowhere. Good luck then trying to find where they're defined so you can understand how they work.

I have a very strong opinion that generating methods at runtime is a terrible feature that should be used only when nothing else can be done.

There are languages which can automatically transform between a.foo(b) and foo(a, b) - for example the D language. Does this make 2.weeks.from_now more palatable? And if it does, then why worry about whether the code “goes on the class” or not? During execution it doesn’t really matter where the code lives, and during development open classes are doing basically the same thing as defining functions overloaded on the first argument.

That looks like you're having to make a Weeks class just so you can do the same thing, instead of adding it to Integer and having it available on any int.

In Ruby at least this example would just be an instance method named Weeks on the kernel class and it wouldn’t really be any more clunky to implement than the ActiveSupport flavor. However because Ruby you’re still reopening a class. You’re just adding a method to Kernel instead of Integer.

That would just be a global method in ruby.

At the top of any file:

def Weeks(arg) end

It could have been done with various less invasive ways. E. G. Clock(2).weeks.from_now (I'm making this up on the fly, there are definitely better names). This wouldn't make your number 2 respond to "weeks" all of a sudden and the cost would be 7 additional characters.

That's negligible.

What's wrong with 2.weeks.from_now ? I get that it hurts your sensibilities (SOLID etc), truth is it's fine. I've seen a good share of Rails projects and never had a problem with this yet. We tend to have a knee-jerk reaction to certain things, and sometimes for good reason, but ActiveSupport is used in millions of Rails projects and nothing horrible happens.

There are things that go wrong when using ActiveSupport, but it's so ingrained in people's workflow that they won't notice.

The one I consider the most annoying: it substantially increases load time. ActiveSupport is huge and just requiring it increases the load time by 1.x seconds. Given what it provides, that's substantial.

The inability to extract a library (or a service) without depending on ActiveSupport is a cost that doesn't exist with the other approaches.

Not to underestimate, your _number_ now responds to `weeks`, and duck typing is the only way you have "interfaces" in Ruby. I can easily picture having a "weeks" or days attribute on some entity and a service object expecting that, now there are subtle bugs when passing accidentally the entity's _value_ instead of the entity itself.

Yeah, they are "minor" things, but the point is dying of thousands cuts.

The last damage is more subtle: devs, even less experienced devs, will feel authorized to monkey patch. In the private codebases I saw (multiple) this is common. It's not a last resort anymore and it ends up becoming a hard problem to debug and resolve.

The ability to monkeypatche pushes devs to NOT design their objects in an extensible fashion. This effectively is the highest damaging consequence, but it's incredibly hard to assess.

> The inability to extract a library (or a service) without depending on ActiveSupport is a cost that doesn't exist with the other approaches.

I'm not sure what you mean; Rails depends on ActiveSupport so if you're a Rails codebase you don't really care, you already depend on it. If you're a gem author it's your own decision if you want to depend on ActiveSupport or not, I'm sure many gems don't depend on it, and others do.

> Not to underestimate, your _number_ now responds to `weeks`, and duck typing is the only way you have "interfaces" in Ruby. I can easily picture having a "weeks" or days attribute on some entity and a service object expecting that, now there are subtle bugs when passing accidentally the entity's _value_ instead of the entity itself.

Never seen this. Not saying it can't happen (can u give an example though? not 100% sure what you mean) but I've never seen it.

> Yeah, they are "minor" things, but the point is dying of thousands cuts.

This is a bit of a hyperbole statement wouldn't you agree?

> The last damage is more subtle: devs, even less experienced devs, will feel authorized to monkey patch.

I think it happens way less than you think; usually in teams of inexperienced people who discover Ruby and metaprogramming for the first time. But the worst monkeypatching bug I've ever seen was actually done in javascript; a guy monkeypatched some jquery method and broke 20000 websites at once (we were a widget startup). Monkeypatching isn't a Ruby thing it's a dynamic languages thing. I don't see Ruby/Rails culture just encouraging people to monkey patch String or Object. The fact dhh and a very experienced team of devs did it, and tested it and perfected it for years, doesn't mean you should do it. This is pretty common knowledge now and I think 99% of Rubyists would agree.

I wish it was true, still, when I look at authentication done with devise, there is extensive monkeypatching done (probably caused by poor design in Devise itself, but still).

> This is a bit of a hyperbole statement wouldn't you agree?

I'm not sure, I see many small problems that slowly leads to what the Ruby community is now. That being said, if you look at how many things ActiveSupport monkeypatches, "thousands cuts" it's not an understatement: https://github.com/rails/rails/tree/main/activesupport/lib/a...

Here is a simple example. Ruby's start_with? method which is confusing because its bad grammar. So AS added an alias and called it starts_with? https://github.com/rails/rails/blob/main/activesupport/lib/a...

Why is this bad? Makes total sense to me. Now both forms work and hopefully it eventually makes it into the language like often happens. But until it does, why not monkey patch obvious mistakes?

Because Ruby has been consistent: there is no method starting with S.

Array has `include?`, Regexp has `match?` and String has `match?` and `start_with?`.

This is consistent: there is no S.

Now when I'm in a codebase, depeneding on ActiveSupport and which parts of it are included, the consistency is now missing. Is it with S or without S?

And what methods DO have the S version and which one do not?

It's a fair point about consistency but its still bad naming. AS accepts both so I don't see a problem. I do hope Ruby will eventually deprecate and rename it to includes? , starts_with? etc.

I don’t think you’re helping your case by holding out Devise as a problem example. Devise is extremely popular, works very well, can easily be extended to support different authentication modes like OAuth, and has saved countless hours for many people. In fact, I haven’t worked in the Ruby world for several years now, but devise is one piece of software that I frequently miss when using other languages.

Devise is well known to have many problems. It works out of the box, but when deviating from strictly the use case it was designed for, there is no documentation and the shortcoming of the design become apparent.

That's where the monkey patching comes in, usually.

But to be clear, I'm stating the facts that many software developer see in the Ruby world when you join an organization that's growing tremendously. As usual, if you fit perfectly in the Rails target and the Devise target, you won't encounter problems.

I don't see it sorry. I don't think Shopify crashes every monday because thousands of devs monkeypatch Object all the time or because AS adds 20 miliseconds to load time. Neither does Github or countless othet huge companies. I agree that after a certain size types make a lot of sense and Ruby or other dynamic languages becomes less attractive but ActiveSupport? Works well.

Shopify has very strict rules to prevent that and they have been working to address that problem for YEARS. They have actually worked on Packwerk (which they use) which enforces the usage of constants when crossing boundaries, rather than any form of interface or duck typing.

The load time of a single test is a recurring problem in the Rails world though, so ActiveSupport adds up.

Monekypatching doesn't lead to crash (it can, but that's not the point), it leads to: - Less extendable code - Less learning - Less maintainable code

Even if the damage is small, given how competitive is the world, why taking the chance for no benefit?

> Even if the damage is small, given how competitive is the world, why taking the chance for no benefit?

Well that's the crux of it here, you see it as damage/no benefit while others in the Rails world disagree. It's a difference of opinions that won't be resolved tonight by arguing on Hacker News. I did like your comment about naming consistency in Ruby though, learned something new.

Oh I love these yes please!

> or example asking whether a variable is present? (truthy, so empty str and empty [] should return false)

Actually this is kind of the whole point of #present? - it's not just a truthiness check.

The only falsey values in Ruby are `false` and `nil`, but in the context of a Rails app you might want to treat things like "" and [] as "not present" (e.g., a user leaves a text field blank).