[mgreenleaf]

> I’ve argued before that this is because the difficulty of building tools depends more on the complexity of programming languages (which are extremely complicated; just see C++) than on the idea, and that, until this changes, no tool can arise without enough sales to pay the large fixed cost of building it.

Language servers helped with some of this. You can write a standard language server that does a very good job and pool the talent of the entire community to add small useful features, instead of having to write a new implementation even if you just want to create a new editor.

Just the other day I saw a comment on HN about wanting something like the whytool, as well as having a way of seeing whether a function has any possible path of being called to/from the current function. Those are very useful features, but would require a large platform of language analysis to build on.

It would be nice if language servers had that as a supported feature, but seems like a difficult problem to solve. The naive approach would be to store every mutation in memory and where in the code it happened, but that might have horrific memory and performance considerations.

For the ancestor/descendant checks, the naive approach would be to have a recursive "find usages" check that checks if it ever hits the target, but, again, going anything past a trivial number of recursions could have an explosion in memory usage and time cost.