|
|
|
|
|
by darby_nine
723 days ago
|
|
In some ecosystems, the tooling is just not that good. To use ruby on rails as an example: if you lean into the IDE's expectations for code layout it works ok, but there will always be generated methods and variables with nothing to show but the name—no documentation, no source, no googleable identifier, nothing. In these cases there's nothing to do but pull out the rails (or library) source to try and discern their intention. In my experience, lisp also has this issue of being very difficult to tool in a general sense, as did aspects of writing c/c++ years ago (maybe recognizing stuff like macro-generated symbols has improved by now). |
|
Most of the common lisp tooling is already present in the language itself. Things like inspect, trace, describe and apropos already gives you the equivalent of most IDEs. I agree with you for some dynamic language and magic methods. It can be hard to trace back the exact function that are being called. But you can always design some tooling for it as long as the code follows the ecosystem convention (Laravel plugin in PhpStorm).
The nice thing about Vim (and other configurable editors) is how easy to mesh existing tooling with the editor itself, without requiring for that extension to be a whole project unto itself.