> Yes it's easier to shoot yourself in the foot in Ruby but that doesn't mean we all design crap code. As your team grows it becomes harder and harder to preve

> Yes it's easier to shoot yourself in the foot in Ruby but that doesn't mean we all design crap code. As your team grows it becomes harder and harder to prevent people from shooting themselves (and the rest of the team) in the foot in such a way, doubly so when you're working in a language that more easily permits it. To your point, if you're working in a smaller team with collaborators that you trust not to make these mistakes, that's a different situation. The inscrutable-method-input scenario that haunts me the most is the case of "options hashes" in Ruby/Rails. Someone writes a method that accepts a single hash of possible options keys, instead of an N-arity method that accepts those scalar values directly. When someone needs to modify the behaviour of that method, the short-term path of least resistance is to just throw another key onto the blob. In the most notorious example I can think of, one of our applications had an options hash with 30 (not an exaggeration) possible keys, after several years of developers deeming that the easiest way to implement whatever feature they were tasked with implementing. It was a total nightmare trying to debug situations where Key A | Key B conflicted in subtle ways with Key C & Key D. Of course there's nothing preventing that sort of scenario from emerging in a statically typed codebase, but I find there's more friction around doing so. Especially if you start out with a rigid interface (with non-nullable keys) that all your callsites must conform to. If someone tries to add a new key to the argument interface, those callsites will need to be updated to match.