4 ms·

I dare say we can call this "yes, for many popular languages, in many modern IDEs". Might I suggest taking a fresh look at IDEs? It sounds like you might be s

by Groxx 9y ago

I dare say we can call this "yes, for many popular languages, in many modern IDEs". Might I suggest taking a fresh look at IDEs? It sounds like you might be stuck in text-editor land, wondering how green the grass is on the other side (or if they even have grass). IDEs do indeed provide grass, and a significant portion of the time it'll even trim and weed itself when you look at it and wonder if it's time to mow.

tomjakubowski 9y ago
IDEs promise a lot, and in many cases they deliver at least some of them. But they're all or nothing: to benefit, you must use their text editor, their debugger, their supported suite of compilers, their documentation browser, their everything. A trend has emerged recently: editor-agnostic language oracles. These tools expose an IPC interface for querying, and in some cases even mutating (i.e. refactoring), source code. They often incorporate a compiler so the type information you get is perfect, and exactly what the compiler sees. Integration with the programmable text editor of your choice (vim, Emacs, Atom, Sublime Text, VSCode…) is a simpler matter of making the right IPC calls. I think this is the sweet spot. I would hate to be locked into an IDE's poor text editor or buggy interface just because they offer some convenient tools. Some examples of editor-agnostic tooling: * CIDER for Clojure and ClojureScript (via weasel or figwheel). The primary editor plugin is Emacs, but vim and Sublime Tex support exists outside the main repository. * rtags and ycmd for C and C++ * tern for Javascript * racer and RLS for Rust * eclipse.jdt.ls for Java * guru for Go Microsoft has even created a protocol for these daemons to follow, which makes editor integration even simpler: https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations https://github.com/Microsoft/language-server-protocol/wiki/P...
- Groxx 9y ago
  Oh yeah, very much agreed (though debuggers are rarely bound so tightly in my experience). And all the language-server-protocol stuff seems exciting and fantastic and I hope it brings about a new breed of tools But that's probably still a year or two away at least for any given language for basic support, much less reaching parity with mature IDEs. In the meantime...

by Groxx 9y ago

tomjakubowski 9y ago

IDEs promise a lot, and in many cases they deliver at least some of them. But they're all or nothing: to benefit, you must use their text editor, their debugger, their supported suite of compilers, their documentation browser, their everything. A trend has emerged recently: editor-agnostic language oracles. These tools expose an IPC interface for querying, and in some cases even mutating (i.e. refactoring), source code. They often incorporate a compiler so the type information you get is perfect, and exactly what the compiler sees. Integration with the programmable text editor of your choice (vim, Emacs, Atom, Sublime Text, VSCode…) is a simpler matter of making the right IPC calls. I think this is the sweet spot. I would hate to be locked into an IDE's poor text editor or buggy interface just because they offer some convenient tools. Some examples of editor-agnostic tooling: * CIDER for Clojure and ClojureScript (via weasel or figwheel). The primary editor plugin is Emacs, but vim and Sublime Tex support exists outside the main repository. * rtags and ycmd for C and C++ * tern for Javascript * racer and RLS for Rust * eclipse.jdt.ls for Java * guru for Go Microsoft has even created a protocol for these daemons to follow, which makes editor integration even simpler: https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations https://github.com/Microsoft/language-server-protocol/wiki/P...

Groxx 9y ago
Oh yeah, very much agreed (though debuggers are rarely bound so tightly in my experience). And all the language-server-protocol stuff seems exciting and fantastic and I hope it brings about a new breed of tools But that's probably still a year or two away at least for any given language for basic support, much less reaching parity with mature IDEs. In the meantime...