We offer you a translation of the article by Piotr Solnica , an experienced ruby ​​developer and one of the authors of the popular Ruby Object Mapper. The translator generally shares the position of the author.


Today I am tired again and feel useless. And this is far from the first time when such emotions have visited me. I usually “let off steam” on twitter, lose some followers, calm down and keep working.

But today I want to burn my negative emotions into something constructive - and, perhaps, useful to other developers. I usually cry on twitter for some aspects of the ruby ​​ecosystem and especially my inability to formulate simple answers to rails developers' questions. Mainly due to lack of time and because twitter is not the best place for long conversations.


This article is an attempt to formulate what is wrong with the monkey-patch in particular and the approach to rails development as a whole, which, in my opinion, may in the long run simply nail down a ruby.
')

Cutting the corners with monkey patching

Yesterday I noticed a pull request in ActiveSupport , which adds an Enumerable # pluck - and it was accepted. Why not? This is useful functionality - let's add it. Moreover, ActiveRecord has such a method - why not add it to the entire Enumerable . Conveniently!

The rails developers do not notice that using the monkey-patch they do something like this:



There is a task. Why search and use a complex solution if you can just apply a blue electrical tape and solve the problem now. The plane landed, so the author of this remarkable method of repair can safely say that the blue electrical tape is an excellent solution to its specific problem (in fact, there is certainly not blue electrical tape, but a slightly different thing . The image is for illustrative purposes only).


This is exactly what we do using a monkey-patch: cut corners and convince ourselves that this is a good solution.

Satisfying current needs does not solve real problems.

Using monkey-patch in Ruby is so simple that the language does not even make it possible to stop for a second and think. Why am I doing this? What problem am I trying to solve? What type of tasks does this particular monkey-patch solve? Is this task part of a large task that can be solved in a correct, well-understood way? Or is it some kind of local task related to the logic of my application and the solution of which should not leave the scope of my application?

Enumerable # pluck returns a collection containing the values ​​selected from the source collection by the specified key - a good, useful thing. The problem is that this method alone does not solve any practical problem. Instead of solving a specific task of transforming data and isolating complexity, monkey-patch takes out some of the complexity above the code, which is why this complexity then begins to creep away from this code: developers start using pluck where necessary and where not.


What if there was a need to do something more complicated than pluck ? The first thing an infected Rails developer thinks about is monkey-patch. Such developers criticize my approach to transforming data into Ruby, arguing that a properly made monkey-patch will result in more elegant code.

The only way to deal with complexity in our projects is to isolate local problems and solve them in simple ways. Using monkey-patch confuses the developer and increases the cohesion of the code.

Do not. So. Do.

How does this affect us?

I see the use of the monkey-patch as tremendously damaging our ecosystem. Many developers, including newbies, are fully convinced that this is the way to solve practical Ruby development problems.

Of course, this is a way to solve problems. But is this a good way? I doubt it. No not like this. I know this is a bad way. And this is one of the main reasons why a lot of ruby ​​libraries are so poorly written: using monkey-patch lowers the quality requirements of the interaction interfaces. If you can use monkey-patch - why should I develop an interface to extend my library?


We cannot continue to develop systems on top of the mountain of monkey patches that Rails is. This reduces our confidence in the changes made, adds complexity to our code, teaches developers perverse practice to patch the code in runtime, makes it difficult to understand what tasks the code solves — the list goes on and on, including such specific cases as interface conflicts, difficulties with debagging because of someone else's changes to our code in runtime and so on.

Last week, developers lost a lot of time because of Object # with_options in ActiveSupport (Two developers, to be more precise. And they asked for my help because they could not understand what was going on). I got “a lot of fun” debugging the strange behavior of my code, only to detect Object # try in ActiveSupport , which replaced my own try method with completely different semantics. What about such a bunch of monkey-patch that NilClass # to_param and TrueClass # to_param methods add just because Rails uses these methods in url_helper ? All these things “made my day” far more than once, and each time it was a question of many hours of debugging. And believe me, I'm not the only one.

Rails can kill Ruby

In 2009, Uncle Bob (Robert Martin) spoke at Rails Conf with the report “What Killed Smalltalk Can Kill and Ruby”. Summarizing: “It was too easy to make a mess” (it was too easy).

And now think about it. Rails is a big pile of that mess, a mountain of monkey-patch, a framework for changing Ruby to your needs. As my friend said, “Rails thinks it is the main part of the toolchain.” Very aptly noticed. The result is a damaged ecosystem and a generation of developers trained to damage it more and more.


The bitter irony is that 99% of Ruby developers have become Ruby developers because of Rails (I really don’t quite understand how this relates to the subject matter). What do we do now? Admire Rails, despite the fact that many of us thanks to this framework have become developers and now see its flaws?

Rails can kill Ruby as many good developers stop or have already stopped using Ruby. I know many of them and deeply regret the losses in our community. Someone told me on twitter that “nothing bad will happen if several experts run away”. But if the technology has such serious flaws that the experts stop using it - maybe something is wrong with the conservatory?