6 ms·
The question was not which library could present an AST for all those languages, but which kind of library format can be consumed from all those languages. And
by Matthias247 9y ago
The question was not which library could present an AST for all those languages, but which kind of library format can be consumed from all those languages. And ideally without FFI and writing complex wrappers. C libraries non very convenient to use from C#, JVM, JS (node.js) or sometimes it isn't even possible (e.g. for JS in the browser).
The question is important, because otherwise one would constrain editors to be written only in a language which is compatible to the library format.
- kuschku 9y agoUsing C libraries from C# or the JVM is very convenient, even today. There’s even automated systems to generate the entire bindings for the JVM, I’ve written bindings myself for a few libraries. You can just generate the interface file for Java from the .h with JNAerator, import it, and you’re done.
- wtetzner 9y agoThat doesn't solve the problem of a segfault in the C library crashing the entire JVM.
- kuschku 9y agoIt does. Because there’s also libraries to automatically spawn a separate JVM and communicate with that via an IPC system. Or even spawn other things. But if you want a system where I have to transfer gigabytes via a JSON IPC bus every minute, sure. That’s totally not going to destroy performance in projects that are several millions of code long with major auto-generated assets. The language server protocol is useless for larger interwoven projects. The same issue appears already with JetBrains Rider (a C# IDE where the C# parser is implemented in a separate process)
- wtetzner 9y agoWhy would you be sending gigabytes of data? You don't have to send the whole project across every time a change is made.
- kuschku 9y agoBecause tiny changes can have major effects, for example, if you use templating (or Java annotation processing) and change a template that’s used everywhere. The IDE has to always stay responsive, no matter what is happening, no matter how large the change is.
- Matthias247 9y agoSuch a change may have a huge impact on the internal state of the language server. But on protocol side it's probably minor. You should just one relevant piece of the new state on the next Goto Definition / Auto completion / etc. request. No need to stream the whole new state from the language server to the client on each update. My current estimation is that the protocol costs are O(1) regarding project size.
- kuschku 9y agoThat's the issue, that shouldn't be part of the language server, but of the IDE. Please read this article, which was previously on #1 on HN, and is from a developer who has implemented IDE support for a language by using LSP: https://perplexinglyemma.blogspot.de/2017/06/language-servers-and-ides.html https://perplexinglyemma.blogspot.de/2017/06/language-server... The developer of the rust plugin for KDevelop said he had to rebuild half of the rust parser because the language server protocol is so completely inadequate that it can't even be used to implement half of KDevelops features. Same with stuff like data stream analysis, how does the language server protocol let you mark a variable and see a graph of where it comes from, and how it's transformed? How do you get proper structural autocomplete? For many features the IDE needs actual full access to the AST. The language server protocol doesn't provide that, so you have to reimplement half of the language server in your own IDE plugin. And it's far too slow. The language server protocol is comparable in quality to Kate's language plugins, which is okay for an editor, but completely unacceptable for an IDE. You can't do proper structural refactoring either. Proper structural extraction, proper autocomplete or ast transformations, automated inline functionality across files. For a lot of functionality you end up having to try and get the AST back from the autocomplete and cursor info that the LSP gives you to fill the IDEs internal data structures, which is ugly, painful, and slow.
- oblio 9y ago> The same issue appears already with JetBrains Rider (a C# IDE where the C# parser is implemented in a separate process) The fact that Resharper (which powers the Rider language processing bits) blocks the VS UI should tell you that this problem lies elsewhere.