Earlier quoted context omitted.
Anecdata that something is effective in 98% of cases is different from provable static verification that works 100% of the time.
> In general it's impossible to "find usages" or "go to definition" > Anecdata that something is effective in 98% of cases is different from provable static verification that works 100% of the time. Ruby has its faults. But you're not making sense complaining first about the "in general" situation, then complaining about a 2% situation. And it is a 2% situation, I'll add my anecdata as verifying 98% (or better) it wo…
The use of "in general" has long established usage in mathematics to refer to properties that hold for all objects in a given collection [0] [1]. Thus, if 2% of those objects fail to satisfy these properties, you cannot say that such properties hold "in general."
> Secondly, you're mixing concepts of static typing and metaprogramming by saying "the language not only fails to equip IDEs and tooling with the static typing information that would grant definitive answers to such questions." Static typing is not the solution, or at least not the only solution, to metaprogramming concepts.
Propose alternate solutions then.
IDEs and tooling (let's leave LLMs and other stochastic methods aside for now) can only inspect the lexical, syntactic, and semantic (types) structure of source code in order to navigate and validate it. Thus, information that is absent from the lexical, syntactic, and semantic structure of the source code, is unavailable to the IDE and static tooling. Ruby, being a dynamically typed language, does not statically encode any structure regarding types, callgraphs/callsites/usages, definitions, or otherwise, in the syntax of the language alone. The behavior of a Ruby program - how its methods are defined, where they are defined, and which runtime objects invoke send what messages to whatever recipients, are only discoverable at runtime, because nobody bothered to put this information in at compile/typecheck time. You cannot discern information that simply is not there.
> For example, if I statically define a Ruby object via RBS, I may still do the things you list that are problematic.
Yes, and this is because RBS is not actually a sound typesystem [2] [3]. You can declare whatever fake types and interfaces you want in RBS; there is absolutely nothing stopping me from simply using `#define_method` to overwrite your implementation, destroying your static guarantees, or using other runtime metaprogramming facilities to delete your method, change its signature, or otherwise violate whatever other invariants you assumed you had when you wrote the static headers/type declarations and had them checked by the static verifier.
It doesn't matter if you statically verify the code, when the language offers innumerable opportunities to destroy those static guarantees, after they were established, at runtime.
> Thirdly, you're complaining about runtime issues making things difficult for the IDE while doing a lookup. What language and IDE do you prefer that does this so much better?
I already provided an example of C# ReSharper upthread [4]. C# actually provides the static typing information that the tooling requires in order to navigate the AST with deductive certainty, not loose approximations or heuristics as in RubyMine.
Out of curiosity, did you study computer science formally at a post-secondary institution, or did you learn from a bootcamp?
[0] https://en.wikipedia.org/wiki/Glossary_of_mathematical_jargo...
[1] https://en.wikipedia.org/wiki/Glossary_of_mathematical_jargo...
[2] https://en.wikipedia.org/wiki/Type_safety
[3] https://www.typescriptlang.org/play/typescript/language/soun...