
Ruby provides a lot of 'sharp knives' - cyberferret
https://m.signalvnoise.com/provide-sharp-knives-cc0a22bf7934
======
gedrap
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.

------
geofft
> _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."

------
chris_7
> 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)

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

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

