Comment by zbentley

But like…this is very telling, no? If major conventions in a language involve runtime debugging/printing actions to just find out where a method is defined (and your approach here is the norm in every Ruby codebase I’ve worked on; this isn’t an attack on you in the slightest) that doesn’t say anything good about the Ruby ecosystem.

Hell, just finding out what methods can be called from a given code location is something that most Rubyists I’ve met answer either with a runtime debugger or hard-fought and non-transferable memory about a particular piece of code.

Like, I don’t need perfectly accurate programmatically-available answers to those questions in my IDE (though that would be nice). I’m fine reading code and working it out if things are added via reflection/metaprogramming. But if the domain of code to read to determine those things is “who knows/could be anything in the codebase or dependencies”, this is a poor quality tool and/or community.

If you read that and think I’m complaining about one specific instance, codebase, or Ruby community habit, I promise I’m not. It’s not about the 2014 obsession with “DSL”s (that aren’t really DSLs); it’s not about method_missing, open classes, pervasive monkey patching, and so on. It’s about all those things, and more, and the overwhelming enthusiasm (with no small side of smugness) with which the Ruby ecosystem doubles down on them constantly.

Is it the language itself? The community? I don’t know, but I know there are plenty of equivalently capable alternatives to both, and that’s enough for me to avoid the hell out of Ruby and Rubyists for a long time to come.

Is Ruby the worst? No, that honor goes to a multimillion line Perl monolith worked on by far too many not-as-clever-as-they-thought-they-were people over far too long. But all the Ruby I’ve worked on is close enough to that experience to make me question the choice of tool.