Ruby provides a lot of 'sharp knives'

Another day, another post taking an extreme position on Ruby/Rails, well no wonder given the author.

While such articles keep getting votes, clicks and attention, they often take an extreme position which does not always result in some useful takeaway.

There is no point to argue that rails is some silver bullet because such things do not exist.

The whole rails issue is pretty damn simple.

There are applications where rails is an amazing fit. Simple, one off CRUD apps is probably the primary example and rightfully so. At the same time, there are complex applications where rails might be a questionable fit and some other, maybe more transparent and more explicit, frameworks might work better, which depends on a lot of factors.

The 2.days.ago example is a good one to illustrate this point. If you are a software shop and your client wants some trivial CRUD application, these kinds of shortcuts are great. A significant share of software projects are just like that and there's no shame in it, there's no point to overengineer.

On the other hand, if you are working on a large project, with many developers working on the code, you need to be really careful with those so that it doesn't get out of hand.

> Because it’s always about other programmers when the value of sharp knives is contested. I’ve yet to hear a single programmer put up their hand and say “I can’t trust myself with this power, please take it away from me!”. It’s always “I think other programmers would abuse this”. That line of paternalism has never appealed to me.

Well, then, I will put up my hand and say "I can't trust myself with this power." It is why I prefer languages with rich and static type systems and languages with a compilation phase (but it isn't just about type systems or compilation). I often want to trust myself in the present, but I know that trust is often misplaced; I don't trust myself in the past to have written stuff I continue to understand and be able to make changes to, the more that I've used sharp knives.

(Perhaps this is a sample bias, in that people who don't trust themselves with this power are unlikely to use Ruby unless forced to. I will admit that I am not a Ruby programmer and don't see myself ever choosing to start a new project in Ruby, though I'm not opposed to working with an existing project in Ruby.)

I deeply understand the value of monkey-patching. I worked for many years on a product that relied on IAT patching/LD_PRELOAD/DYLD_INSERT_LIBRARIES to intercept all reads and writes. My personal domain is ldpreload.com, and I've written an LD_PRELOAD/DYLD_INSERT_LIBRARIES library for Rust. But using a preload library is being very explicit about opting in to monkey patching. The option of spooky action at a distance is great; having it without any clear opt-in to what spooky action is happening and at what distance is an entirely different matter.

Similarly, I have sharp knives in my kitchen drawer, but they're all in blade guards/sheaths. I know how to use them safely, but when I don't want to use them, I want no risk of them cutting anything.

On another note, dismissing this as "paternalism" is sort of wrong when the objection, as I hear it, is generally "I have tried to maintain codebases from other people, and they should not have been trusted with that power, it turns out."

> Because the flip side of monkey patching is the power to do such feats of wonder as 2.days.ago (which returns a date two days back from the current). Now you might well think that’s a bad trade. That you’d rather lose 2.days.ago if it means preventing programmers from overwriting String#capitalize. If that’s your position, Ruby is probably not for you.

You can implement this stuff in Swift (and C#?) in safe manner. It's not strictly related to "monkey patching", it's just being able to write extensions to type. The issue is with some other library also being able to do that, and them fighting over the behavior.

(2.days.ago is also a weird API as it depends on calendars, etc. - stuff that ought to be explicit)

To me, it isn't about the knife blade being sharp or dull, but rather how slippery of a handle you have attached to the knife. Monkey patching is a sharp blade, but concerns are a slippery handle.

Concerns make reasoning about code more difficult once large enough. Further, the difference between a "just-right" sized code base and a confusing bloated one is often time and consistency. When nobody has the time to do the necessary refactor, the concerns start interacting. This is the aforementioned slippery handle.

I think it's quaint that DHH feels the ability to use "concerns", basically Ruby's module feature, is a sharp knife. I guess it upsets the "there are only three possible places to put your code" utopia.