There's a tradeoff between coupling and cohesion. All the books and talks are about decoupling because that's the interesting part. The problem is that in poor codebases you find everything has been decoupled and the complexity is a nightmare. As Adele Goldberg said: "“In Smalltalk, everything happens somewhere else.” It's better to have a system where you only decouple where and when you want to because you have decided that paying the cost is worth it.

They used to pay me to turn monoliths into microservices, now they pay me to turn their microservices back into monoliths...

I've worked with Java, Ruby and Python but I don't get your point. Can you recommend any resource to help understand what you mean? Or maybe some short examples in Python and Ruby that would highlight how implicit imports allow solving problems in a way that explicit imports prevent?

Not the parent, but I’ve found Sandi Metz conference talks to be an amazing resource for learning more about this message focused approach.

But back to the original point, Sandi Metz wouldn't suggest that implicit imports are good.

Sandi Metz's talks, and Avdi Grimm's MOOM course.

Ok, but Objective-C also does messages and most of them are defined statically and can be easily searched for in a codebase. I’m not saying Ruby needs header files to send messages to something, but being able to figure out where the code for something is isn’t off the table for languages with dynamic dispatch and it can come in handy.

For that, there's

    object.method(:name).source
    object.method(:name).source_location

but frankly this is still thinking in a rigid mindset that suits other languages better. Ruby isn't just "dynamic dispatch"; a typical metaprogramming technique handles all incoming calls without named methods, or by dynamically writing the code.

To put it bluntly, assuming there's a method on the other side of your message, is practically the antithesis of Ruby.

It's similar to the category error that leads folks to conflating type with class, and writing type checkers that look for class signatures.

While freeing to write, that is horrifying to inherit.

That isn’t code you write in an application. The topic was how to find a method’s handler, this is how it’s done in the REPL.

Or if you mean, dynamically instantiated methods, those are found throughout Ruby and its ecosystem, and the reason it isn’t horrifying is that the language has terrific support at the REPL for developers needing reflection.

Yeah this is pretty much why I decided I didn't want to write Ruby anymore. You may be right that this is the philosophy of the language, but if it introduces a speed bump or cognitive overhead when trying to understand what a snippet of code is doing (and I contend that "there might not even be a method there responding to your message" is a speed bump), then it's not a good thing, even if it's clever and somehow ideologically pure and interesting. I can appreciate programming languages as art pieces, but when I'm at work I want them to just be a tool.

The best features about this bridge are that it's made out of soap bubbles and it doesn't necessarily span the river at any given time. This flexibility is wonderful.

I worked with Ruby for two years. The metaphor is apt when considering software development as an engineering discipline. It was certainly not meant as snark. You disagree, that's fine.

Not really sure what you think I disagree with, since the metaphor is so vague and wishy-washy it could apply to anything from theology to stamp collecting, but it sounds like trying to conflate late binding with some manner of bad coding style.

Well, since I have been privileged to work with several really great Ruby teams over the last couple of decades, whose large and well-structured code uses metaprogramming techniques yet remains easy to follow & comprehend (and debug and extend), and who remain splendidly productive to boot, I can say, if this bunch of guesses at the intended meaning of that "soap bubble" metaphor hold water, then yeah, I disagree.

Conversely, shitty code can be (and is) written in explicit import and early-bound languages. The enterprise world, for example, is riddled with massive hairballs of brittle, unmaintainable, boilerplate-heavy Java.

All of which only goes to show that people, not the programming language, are the problem.

I can't think of a single point in my RoR career where this has come up. How do you even do Java-like OO when classes are so loosey-goosey anyway?

Though having suffered in a Rails codebase written by Java engineers, I definitely agree that a light touch is needed with OO -- though composition has its own difficulties and together this forms one of my bigger criticisms of Rails.

There's plenty of people writing java-like code in Python too, just check Amazon SDK for python or GCP SDK, it's a mess, I don't know if they get frustrated but they do get SDK users confused and frustrated.