solnic.codes - Latest Comments

Re: WHOOPS! Thoughts on Rails, forking and leadership

Foo Bar — Mon, 07 Nov 2022 16:25:27 -0000

You clearly didn't read "Rails is omakase", did you now?

Apple did not became successful because Jobs said "let's ask out users what they want, and remove what they don't want". Nor did Gates. Nor Bezos. Carnegie. Rockefeller. Page. Brin. Branson. Ford. Musk. "Oi, Musk, I don't like that your cars have electric motors, remove that pile'o'junk right-oiking-now! And put the petrol back in there, pronto, mate, you hear me?? And remove that creepy autopilot, it's freaking me out! And LIDAR! I want LIDAR, NOWWWWWWWaaawawawaww".

I have a reason to believe those people, nor their companies, would not became as successful as they are/were, if they were listening to every single unhappy rant out there.

You can not make a copy of Microsoft and move on with a mix of communism/democracy ruled by the end users. You can do so with Rails though. And you're right, it'll bring problems and fragmentation, but if your approach is better and if it really worth the switch - then, eventually, ecosystem will move to your fork. But if you really look at this and realise that your fork will never become a worthy competitor - then, maybe, by a chance, that idea of yours, your vision is not that good after all, huh?..

And, as a final note, when you feel like you, and a handful of likeminded people around you, is right, while hundreds and thousands of other people around you are, in your opinion, wrong, then maybe, just maybe, they're not the ones who are wrong, but you are. Give it some thinking, huh?

Re: Cutting Corners or Why Rails May Kill Ruby

Foo Bar — Mon, 07 Nov 2022 15:44:45 -0000

A bit late to the party (call me a slowpoke, but hey), but I got a bit of a reality check here for you fellows.

Rails are bad.

Okay.

They do lots of bad, wrong, despicable things.
They promote sloppiness and laziness.
They are bloated and their author is arrogant.

But they're comfortable.

Fast-food. Instant noodles. Single-use dishes. Junk food. Nail biting. Smoking. Drinking. Car riding instead of walking. Chairs! Yes, chairs! - sitting a lot is bad, but we spend no less than 8 hours in it each day! Eating in the bed, wearing t-shirts to work, happy socks, non-leather shoes, turtleneck-jeans-and-sneakers instead of Desmond Merrion Bespoke and Bruno Mars classic oxfords (feel snobbish yet?). TYPING. Typing instead of coursive writing! Are you too old enough that you were taught in school to write by pen in a pretty cursive manner? Because it should be pretty! It should be right! When was the last time you cared about it though?..

We do all those things. Eat, wear, use, do, type on keyboard. Some more, some less. But do tell, do you not eat junk food? Do you not enjoy it?... A fat burger full of heart-attack-inducing cheese? Chinese takeout? Cheesier-than-your-jokes pizza? A most comfortable plimsolls your feet has ever made love to but that are considered plain wrong by some snobbish folks from Ivy-something? Because they're *-ing comfortable! Tasty! Cozy! Comfy, lovely, snuggy, warm feeling that you just enjoy every single goddamn day. *in a cranky voice* But it's wroooong. Caw. Caww. Wrooooooong. Well you know what? Go be Ivy somewhere else. And leave us to enjoy our sins in peace.

Here, have a potato: https://9gag.com/gag/a85VgLV

Re: Rails is not written in Ruby

Dkdld — Mon, 07 Nov 2022 14:50:44 -0000

The analogy is wrong because you have misunderstood languages and dialects. Dialects are not freak versions of languages; rather, what is perceived as standard forms of languages are also dialects, albeit with power (an army, economic resources, political rule over surrounding areas) behind them that allows for deeming them as the standard forms. Dialects come first; languages second. To call one dialect more correct that another is nonsensical.

Re: Get Rid of That Code Smell – Control Couple

Bawenang Rukmoko — Thu, 03 Mar 2022 08:20:02 -0000

While I agree with you that it is a good way to remove the smell using subclasses, I’m not sure that you are getting some performance boost. I’d reckon the opposite. Because by subclassing, you are adding a lookup to the vtable. Furthermore, it will make the distance of the object in the memory larger. Thus, that is a cache miss (ie. it can’t be cached by the L1 and L2 caches).

Re: Rails is not written in Ruby

Francesco Belladonna — Wed, 16 Feb 2022 23:03:26 -0000

It suggests that there might be a missing layer in between (I don't know the internals, I'm speculating). I'd put having that layer as a hard requirement for any DSL: DSL should just delegate to simple objects underneath. Now of course, that call will not look pleasant, but the DSL is there to hide it.
This approach brings on the table a very simple but powerful concept "Replace the API when needed". Turns out, it's a very useful concept, routes + Controllers do the same thing.

There is also another point that is overlooked: DSL doesn't imply having a special sytnax. A "DSL" could be a bunch of objects interacted in the traditional way, just with a well-known language.

As for schema definition, Ecto (elixir) is a good example of what part should be "custom DSL" and what part should be "just functions" (or objects in OOP-land). I wish there was something like that in the Ruby world. It's a simple data structure built on conventions.

Anyway, sorry, I didn't want to turn this into a post this. I'd choose dry-rb over Rails activemodel (and attributes and validations) any time. I do think there is room for further improvement.
It would be easier to discuss this on a virtual call though, the amount of chat that would go into this is extensive.

As for Rails "monopolize" monkey patching, true, although the developers that reach a certain do develop a distaste for what Rails has done.

One point that made me scratch my head is the example about TimeCalc. I think the API could be greatly improved without any sort of monkey patching. An example:

=> TimeCalc['2019-03-14 08:06:15'] + [3, :months]
TimeCalc.call in this case would need to do some type checking, but `call` would be the "DSL" part of it, the one that does the dirty stuff. TimeCalc.new should only accept one type, which could be Time

There is the option (yeah, monkey patching) of making a CapitcalCase method:

=> TimeCalc('2019-03-14 08:06:15') + [3, :months]

This is indeed monkey patching, but the chance of conflicts are low if the gem name is used as the method name, which could as well become a ruby convention.

Re: Rails is not written in Ruby

... — Tue, 15 Feb 2022 21:46:45 -0000

It's amazing that 15 or so years later that this is still something we have to debate about. The early JavaScript days like Scriptaculous\Prototype and others learned the hard way at the same time. Surprised the community hasn't moved past this?

Re: Rails is not written in Ruby

solnic — Fri, 11 Feb 2022 02:42:26 -0000

I'm so glad you mentioned this. There are methods in ActiveSupport that only exist because Rails' design is missing crucial abstractions. One of the biggest design flaws is the lack of proper coercion and validation abstraction for external input. `presence?` and `blank?` are not needed, period. They exist only because Rails' has taught people to pass unprocessed input directly to the domain "layer" where things like hashes with string keys or uncoerced booleans create more complexity, complexity that is not needed.

This is one of the reasons why I created dry-schema because external input should always be preprocessed before you can work with it. Hashes with string keys should be converted to symbolized hashes, rather than using HWIA (which is a huge code smell BTW). Boolean values should be coerced into `true` or `false`, so that there's no ambiguity about what type of objects represent true or false. If `nil` is allowed and can have a different representation (ie a empty string), then such input should be coerced to `nil` rather than allowing empty strings to be passed down and handled via `blank?` or `present?`. If you have a value that can be an empty array *or* nil, you also don't need `blank?/present?` and instead, you could use Maybe monad, which is a safer way to handle `nil` because *you must* handle the case where something is nil, which ensures you won't get the most famous of all exceptions.

> There are lots of other examples of core problems with ruby that are mitigated by ActiveSupport

This is exactly what I'm talking about. People are used to solving problems using questionable techniques *because* of ActiveSupport. These are not core problems with Ruby, these are mostly problems with how Rails is designed.

Re: Rails is not written in Ruby

solnic — Fri, 11 Feb 2022 02:28:53 -0000

> I think dry-rb tries too much to "protect from external developers" the internals of dry-rb and there is an over-use of DSL.

I suspect it's an impression you have. You're probably talking about dry-schema/validation specifically. Using POROs with a nice API is actually how dry-rb gems are designed. People keep pointing at dry-schema's DSL as if everything else was so DSL-heavy, which is not the case, and dry-schema is *a very special type of a library*. I can assure you an advanced DSL is needed for defining schemas, if you were to define a schema with 10+ keys using PORO-oriented approach, you'd suffer. There's a similar sub-thread about this here, you can check it out: http://disq.us/p/2ml84xw

There *is* a PORO-API for defining schemas, but it's too low level at the moment, so it's not exposed as a public API (yet). ie:

dry-schema> Dry::Schema::Macros::Required.new(:name).to_ast => [:predicate, [:key?, [[:name, nil], [:input, Undefined]]]]

You could have a convenient shim on top to automatically put together a schema, but there's *much more* involved in a schema creation process which people don't know because it's hidden by the DSL. There are types, there's coercion, there's key validation, there's a pre-coercion validation and so on. If you were to define all of that using PORO approach, schema definitions would become extremely verbose.

Re: Rails is not written in Ruby

Francesco Belladonna — Thu, 10 Feb 2022 22:12:42 -0000

Thank you, I appreciated the article and agree with the entirety of it.
I do have a point against dry-rb libraries because they do have their own internal DSL, but don't provide also "PORO" API. To clarify, my rule of thumb is: a DSL should just delegate functionality to plain old ruby object, so that people can opt-out (or enhance, or change) of the DSL and instead just use ruby classes for the purpose.

Everyone is familiar with:

CoerceIntegerFromString.new(some_data).call

But you actually need to study that

# dry-validate something.filled(:string)

Of course this example is trivial, but this should be extended to every DSL.
I think dry-rb tries too much to "protect from external developers" the internals of dry-rb and there is an over-use of DSL.
Remember, everyone is familiar with a simple ruby object. Familiarity is very important, but for some reason we continuously and constantly expect people to learn "new programming languages" (dialects) because they look more like English.
I'd rather be able to onboard 100 people because they all know Ruby than make the DSL more English-like so that it looks nicer.

Re: Rails is not written in Ruby

Caleb Meyer — Thu, 10 Feb 2022 17:15:13 -0000

In general, I don't like monkey patching either. But ruby has some real deficiencies that aren't addressed by the core/standard library.

Since only nil and false are falsy, a lot of conditionals end up having to roll their own logic for falsy values like empty array/hash/string. E.g. in python or js you might do
```
data = fetch_some_data()
if (data):
# do stuff with data
```

In ruby you always have to do something like `if data && data.length > 0`, assuming it even has a length. Adding active support means you can do `data.present?` or `data.blank?`.

Similarly, ruby 1.9 added JS style hash declaration, which is great and uses symbols as keys. But if you try to read a hash from an unknown source or partially known source, or where some monkey is patching in string keys, now everything is a mess. Was it `params[:id]` or `params["id"]`? Mutable by default strings was a mistake, and it's getting corrected in ruby 3, but it's far too late. Active support adds HashWithIndifferentAccess, and patches Hash to have `.with_indifferent_access` to fix this.

There are lots of other examples of core problems with ruby that are mitigated by ActiveSupport. If I could merge all of it into ruby core, I would.

Re: Rails is not written in Ruby

dorcus_maximus — Thu, 10 Feb 2022 17:00:19 -0000

I've been a Rubyist for over ten years. Not once have I ever worked on a Rails project. What I have done is inherit a large(!) amount of code in which one of the original authors (the boss, an old SmallTalk wizard) was quite liberal with monkey patching. Holy Moly, what a pain in the patootie that was, especially when I was a more junior programmer and hadn't the chops to quickly extract myself from each morass.

I'll admit to monkey patching in my early days. I no longer even think about doing so. I can usually acheive my goals in some other, more compartmentalized way. On the rare occasions when I do want to add functionality to a core library or something from stdlib -- Refinements! I see others are mentioning refinements too; and for good reason. They're right, they don't cover every base that monkey patching does, but perhaps those use cases that refinements don't cover shouldn't be implemented at all?

Re: Rails is not written in Ruby

Adam Runner — Thu, 10 Feb 2022 13:36:02 -0000

I think this is an excellent article - software development and engineering is always evolving. I've personally never thought too closely how as Rubyists we're told to avoid monkey patching, but also be okay with the monkey patches from ActiveSupport.

Composing classes and using dependency injection is a significantly easier to understand pattern, it does take away a bit from the "magic" of Ruby on Rails ...though I'd argue that it's okay to see how the magic works.

Re: Rails is not written in Ruby

solnic — Wed, 09 Feb 2022 03:37:18 -0000

> You argue that Rails have the "monopoly for monkey-patching", but by adding a DSL with no class/object equivalent version, you also have a "monopoly on the API" - filled(:str?) is WAY more beautiful than filled(NumberString)

I'm not sure what you mean by that. Everybody can implement DSLs without causing issues like monkey-patching. As I understand, you're talking about various limitations of DSLs depending on how they are implemented.

Regarding APIs for transforming schemas, it's just still a WIP. Like I said, you can merge schemas, you can even compose schemas like `schema1 & schema2` and more features will be implemented eventually. An object-only API would be very simple to implement, but you still need a formal representation of a schema if you want to easily process it, ie export it to another format, generate another representation etc.

Your approach with using hashes is actually similar to what's going on under the hood, it's just that we have the AST, and you have a Hash. Processing ASTs is much simpler than processing Hashes though, that's why we have it.

> I can do the same in dry-schema and dry-validations. But can I write a dry-schema and just "include" it in Hanami?

This will be possible in Hanami 2.0

> Or can I write a dry-schema and, before adding it on a Hanami controller, make all fields optional?

There's no public API for transforming schemas like that, but it will be done eventually, most likely in dry-schema 2.0.

Re: Rails is not written in Ruby

solnic — Wed, 09 Feb 2022 03:28:32 -0000

FYI disqus decided that you're posting spam, that's why your other comment didn't show up. I just fixed it by adding you to a "trusted users" list. Sorry about that, I'm planning to migrate from disqus to something else eventually.

Re: Rails is not written in Ruby

mauricioszabo — Tue, 08 Feb 2022 18:05:52 -0000

I'm not sure I'll be able to answer, because Discuss is being weird, but I meant that RSpec have magic, not monkey-patches. Yes, I love the convenience of RSpec but I have to mention that I did got into trouble multiple times with it_behaves_like, and the one-liner syntax...

I mean, they are useful and the code really reads like English, but when you have to declare more than five "let"s and a subject to be able to reuse tests from other places (a pattern that I saw way too many times), I kept thinking if there was any other way that I could compose things...

Re: Rails is not written in Ruby

dgutov — Sun, 06 Feb 2022 09:06:17 -0000

I agree with this in principle, though in practice using AS judiciously feels pretty comfortable.

We should also also note that since a few years ago Rails offers the option of loading as little from ActiveSupport as possible: config.active_support.bare.

And the list of features that *every* component of Rails depends on is pretty small: https://github.com/rails/ra...

Re: Rails is not written in Ruby

Alex Dowad — Sat, 05 Feb 2022 07:32:24 -0000

Thanks for the article. My personal position is that monkey-patching of core classes is the reserve of top-level application authors and should not be done by libraries,unless the client programmer explicitly opts in to it. If they don't opt in, the library should still be usable, though perhaps with slightly more verbose syntax.

Re: Rails is not written in Ruby

JonRowe — Sat, 05 Feb 2022 04:03:39 -0000

👋 RSpec maintainer here, RSpec has had a zero monkey patching mode since the release of RSpec 3 in 2014, and will be the only option in RSpec 4.

The custom matchers may look like global methods but they are not, your tests run inside an instance of an RSpec example class, and the matchers are methods on that class that return composable classes. Its possible to instantiate matchers directly (and we do internally) if you need to (and is how we compose some matchers ourselves). You could argue creating new matchers (with or without our DSL, we support both) is monkey patching our library, which I would say is a fair and valid use of monkey patching, but it doesn't leak out into the rest of the application eco system, and we go to lengths to make sure we don't poison any of your code with our internal needs, even trying very hard to avoid requiring anything in the standard library (literal require that is)

Re: Rails is not written in Ruby

Sebastian Wilgosz — Fri, 04 Feb 2022 12:59:11 -0000

It took me years to transfer from falling in love with monkey-patching to composable objects with clear boundaries and more abstractions.

When I was Junior, still at University, and I realized the heavy usage of monkey-patching, I felt sth is definitely wrong somwhere but it was not possible to argument the less convienient path, especially when more experienced rails developers said otherwise.

And I think this is a big problem. Decrease of ruby popularity shows that people are just tired with the mainstream (rails) approaches that generate problems over time so people switch.

I hope by publishing more such great argumentations will have positive impact though! Great argumentation!

PS: now I finally understand why you say "czy"!

Re: Rails is not written in Ruby

Sebastian Wilgosz — Fri, 04 Feb 2022 12:30:07 -0000

> It’s not the first time when I talk about this topic, and I actually really don’t like to repeat myself

I treat my blog more like a garden and I don't think one should ever hesitate to go back and tweak older articles.

Re: Rails is not written in Ruby

Matt Armstrong — Fri, 04 Feb 2022 12:00:30 -0000

> For the love of Matz, the alternative is to just use Ruby.

To start, I almost completely agree with you from a software engineering standpoint. Mission critical gems should usually aim to minimize their impact on code that requires them.

On the other hand, one thing that has always attracted me to Ruby is that it does not always prioritize traditional software engineering values. In other ecosystems I am often expected to use pure, established idioms. Ruby, on the other hand, gives me the freedom to teach the language how I want to express ideas in straightforward code, to bend the rules, to have fun. In this way it is not unlike Smalltalk, Forth, Lisp -- all languages invented before everybody was so worried about boring issues like long term maintainability of code and "composable APIs". :-) I am exaggerating for effect, here, clearly.

I think it is funny you invoke Matz (in a joking way), because Matz clearly designed Ruby to make monkey patching easy. Have a read of this old article from 2003, especially the section on "Orthogonal versus Harmonious": https://www.artima.com/arti.... There are examples of monkey patching within the standard Ruby libraries, too. Require some thing and suddenly some other class has more methods!

I also think "1.day.ago" is an example of a monkey patched API done right. I'm less happy with API's like https://github.com/zverok/t.... "1.day.ago" is harmonious. It reads exactly like I think. 1 is still a number -- monkey patching doesn't change that. "day" applied to a number is a duration, and "ago" applied to a duration gives me a time in the past. All very natural, assuming the grammatical rules of English feel natural. In contrast, time_calc lib asks me to figure out how to say the same thing in a more convoluted way, with parentheses, etc. It requires a translation step between the concept as I think of it and the program code, which is a chore. I write Ruby precisely when I want freedom from such chores.

You say ActiveSupport has a monopoly on monkey patching, which isn't really true in practice. Has the set of monkey patched methods in ActiveSupport really undergone massive churn over the years? Other gems are free to monkey patch. If they choose not to it isn't because ActiveState makes a different choice. Why be happy with granting that same monopoly to the Ruby core? Who is to say that some other group of people get to decide what dialect of Ruby I prefer to write in? How do I try out ideas and prove their utility before adoption into the core? Why must I always do this "in my own code base" and why is sharing these ideas bad?

As a side note, your validate_phone_number example is interesting because some other functional programming languages solve that problem with the "arrow operator", which is like chaining but without an implied receiver object. The desire to want to monkey patch is also, I think, a natural consequence of the OO design pattern. One issue with Smalltalk systems, which Ruby borrows heavily from, was that their class hierarchies often became rats nests of methods high up in the inheritance chain (just look at Squeak Smalltalk at some point -- there are crazy things like the Object class knowing how to play itself as a sound or animation, etc.). I think this set of problems is one reason OO design is falling out of fashion.

Now, to finish where I started, from the point of view of prioritizing maintenance chores over all else, monkey patching has clear drawbacks, and on this I completely agree! I hope to point out, though, that this is not an issue of absolutes. The drawbacks are merely that, and monkey patching also has benefits.

Re: Rails is not written in Ruby

gosukiwi — Fri, 04 Feb 2022 10:24:49 -0000

This is always an issue for small projects. If you are used to work with Rails, you'll be surprised how many things you take for granted.

I remember seeing a quiz asking which features were from Rails (ActiveSupport) and which from Ruby. Most people just failed miserably distinguishing them, inlcuding me :P

Re: Rails is not written in Ruby

Brooke Kuhlmann — Thu, 03 Feb 2022 14:50:45 -0000

Hey Piotr. 👋 Great article, and thanks for taking the time to write this. Now I have one more source of truth to pull from when people bug me about this too because it drives me up the wall as well.

One solution to this problem is to use refinements (I commented on this below as well). I'd be curious what your thoughts on this are and whether that bolsters your argument or detracts from it?

Here's my article and gem which I've written at great length on in case it's of interest and helps provide more background:

- Article
- Gem

I'm not saying refinements are a panacea. Like anything, when used judiciously, I think they are quite powerful and much better than monkey patching.

Re: Rails is not written in Ruby

Brooke Kuhlmann — Thu, 03 Feb 2022 14:40:43 -0000

I'm a fan of refinements for this very reason. Here's the Refinements
gem that I use in a lot of my work. ...and here's my Refinements
article that breaks all of this down even further. Maybe
that's some encouragement? 😅

Re: Rails is not written in Ruby

Cassio — Thu, 03 Feb 2022 12:55:59 -0000

I wonder how rails would look if it used refinements.

I also would love to see something on ruby like module exports from python/javascript