4 ms·
I'm not the OP, but I strongly agree with their statement. The problem is not Ruby's dynamic typing; table stakes here is the good-not-great tooling support fo
by zbentley 3y ago
I'm not the OP, but I strongly agree with their statement.
The problem is not Ruby's dynamic typing; table stakes here is the good-not-great tooling support for other dynamic languages like Python and JavaScript, not the great support for more typeful languages.
I think Ruby plays really poorly with editor/static analysis tooling because of the culture and conventions around blocks.
The fact that so many libraries/frameworks in Ruby use the very common pattern of "provide variables/context/symbols to blocks via scope (rather than block arguments)" massively increases the difficulty for tools to provide useful type info, completions, and validity analysis. As a pattern, "scope injection" is just harder to statically analyze from the outside, and, while not ubiquitous, it's alarmingly normalized in the Ruby community.
I'm not sure if it's the chicken or the egg for many Ruby programmers' heavy reliance on the REPL for autocompletion and probes of local/instance/class/global variables. Regardless, editors' and linters' usefulness is reduced in proportion to the dominance of this pattern across the Ruby ecosystem. Heck, even when heavily block-oriented libraries are well supported by IDEs (rspec, rails) the support turns out to be based on brittle pattern matching and hardcoded guesswork in the tools.
There are other cultural (e.g. tendency to overuse stringy method calls and method_missing, though this thankfully seems to be less common these days) and technical (e.g. autoloading, open classes) things that increase the difficulty of writing good Ruby tooling, but I suspect that they're much less responsible for the anemic tooling landscape than block-oriented programming.
I really do think it's largely cultural. You can do block/scope-injection -based programming (and eval, and method_missing via getattribute, and so on) in e.g. Python without too much trouble, but it's not nearly as much of a community norm as it is in Ruby, so people do it less.
And that's OK! Many prolific Ruby programmers have found ways around the tooling deficit and are productive with the language, and Ruby remains a go-to for people writing "DSL"s (though I find when people refer to DSLs in ruby they really mean the combined effect of parens-optional plus method_missing plus block scope injection), so this seems like far from a fatal flaw.