3 ms·

No. The point is that while we need analyzer for each language, the connections between the editors & the analyzers have no problems to be N*M because they're v

No. The point is that while we need analyzer for each language, the connections between the editors & the analyzers have no problems to be N*M because they're very small. So we don't really need a protocol like LSP. But the rise of this protocol caused people to write independent, non-per-editor analyzers, and this is indeed necessary. I completely agree with that.

codeflo 5y ago
Hmm, maybe I misunderstood the author’s point slightly, but I find what you suggest the argument was even less convincing. Here’s the history: Every editor has a language abstraction already. And some language analyzers had an “editor abstraction”, perhaps notably Roslyn for C# with its programmable refactoring rules that worked in multiple editors. None of that was new. But that’s still N*M if you do the math, so that graph was never completely filled — for the obvious reason that this would have been practically impossible. No mystery about it.
- mgdlbp 5y ago
  And considering how VB.NET was incorporated first-class besides C#, Roslyn seems rather ahead of its time, with both language abstraction at the compiler level and language-agnostic analysers based on semantic info. I still can't get over the awesomeness of being able to just throw together a fully supported custom analyser from a template—unique to Roslyn to this day, AFAIK.
jerf 5y ago
If that was the point, it'd be a wrong point. The connections would not be small. They would be small on the 30,000-foot view, but up close at the implementation level each and every one of them would come with a crapton of assumptions about how they operation that would at times require architectural changes to the editor to work. This one "helpfully" works based on the files on the disk. That one connects via Protocol Buffers. Each of course have their own set of error messages and a protocol to implement. Whoops, this one is more synchronous than I thought. Whoops, the way this one works conflicts with my incremental compile feature. Crap, this one turns out to implicitly require a certain threading model. Oh dear, this one wants a stream of every keystroke made, but that one wants the entire file sent over when we want to run an analysis. Aw heck, our IDE model requires the whole file to be sent over for incremental analysis but doing that six times a second kills my whole dev machine, and doing it not six times a second makes the latency intolerably slow compared to our current custom implementation for our dominant language. The original NxM problem is that each language needed support per editor and each editor required support per langauge. While "each language writes one custom server" and "each editor has to support each language's custom protocol" would still be an improvement, it wouldn't be enough of one. Now, the idea that an editor can just implement this protocol and magically all the unicorns start singing in unison is a pipe dream as well. But what it does is make something that is completely infeasible for even a well-funded commercial team into something that some new little open source editor can afford to start doing. Support for Haskell may be a bit rough until someone wants to use Haskell in that editor and can fix the editor support for Haskell specifically, because of this quirk and that quirk and the other quirk (the quirks will always be with us), but at least it's in the realm of possibility now instead of a ludicrous pie-in-the-sky idea.
andrewla 5y ago
I mean, this is theoretically true, if an editor provided a language-agnostic protocol for talking to potential semantic plugins. The article says > Rather, a language should implement a server which speaks some protocol, an editor needs to implement language agnostic APIs for providing completions and such, and, if both the language and the editor are not esoteric, someone who is interested in both would just write a bit of glue code to bind the two together I mean, yes, ideally that is what should have happened, but the first editor to actually do that was VSCode, and the protocol it chose is called LSP, so that's where we are.
- afdbcreid 5y ago
  But it doesn't need to be a protocol, just some API. And VSCode actually does that - I think it doesn't even have LSP builtin (but I may be wrong).
  - matklad 4y ago
    You are correct, and this is indeed one of the important facets I try to illuminate. VS Code doesn't support LSP natively, it just exposes a bunch of APIs to provide IDE features. Actual LSP support is implemented as a separate library on top of these API, an adapter pattern in the wild.

codeflo 5y ago

Hmm, maybe I misunderstood the author’s point slightly, but I find what you suggest the argument was even less convincing. Here’s the history: Every editor has a language abstraction already. And some language analyzers had an “editor abstraction”, perhaps notably Roslyn for C# with its programmable refactoring rules that worked in multiple editors. None of that was new. But that’s still N*M if you do the math, so that graph was never completely filled — for the obvious reason that this would have been practically impossible. No mystery about it.

mgdlbp 5y ago
And considering how VB.NET was incorporated first-class besides C#, Roslyn seems rather ahead of its time, with both language abstraction at the compiler level and language-agnostic analysers based on semantic info. I still can't get over the awesomeness of being able to just throw together a fully supported custom analyser from a template—unique to Roslyn to this day, AFAIK.

jerf 5y ago

If that was the point, it'd be a wrong point. The connections would not be small. They would be small on the 30,000-foot view, but up close at the implementation level each and every one of them would come with a crapton of assumptions about how they operation that would at times require architectural changes to the editor to work. This one "helpfully" works based on the files on the disk. That one connects via Protocol Buffers. Each of course have their own set of error messages and a protocol to implement. Whoops, this one is more synchronous than I thought. Whoops, the way this one works conflicts with my incremental compile feature. Crap, this one turns out to implicitly require a certain threading model. Oh dear, this one wants a stream of every keystroke made, but that one wants the entire file sent over when we want to run an analysis. Aw heck, our IDE model requires the whole file to be sent over for incremental analysis but doing that six times a second kills my whole dev machine, and doing it not six times a second makes the latency intolerably slow compared to our current custom implementation for our dominant language. The original NxM problem is that each language needed support per editor and each editor required support per langauge. While "each language writes one custom server" and "each editor has to support each language's custom protocol" would still be an improvement, it wouldn't be enough of one. Now, the idea that an editor can just implement this protocol and magically all the unicorns start singing in unison is a pipe dream as well. But what it does is make something that is completely infeasible for even a well-funded commercial team into something that some new little open source editor can afford to start doing. Support for Haskell may be a bit rough until someone wants to use Haskell in that editor and can fix the editor support for Haskell specifically, because of this quirk and that quirk and the other quirk (the quirks will always be with us), but at least it's in the realm of possibility now instead of a ludicrous pie-in-the-sky idea.

andrewla 5y ago

I mean, this is theoretically true, if an editor provided a language-agnostic protocol for talking to potential semantic plugins. The article says > Rather, a language should implement a server which speaks some protocol, an editor needs to implement language agnostic APIs for providing completions and such, and, if both the language and the editor are not esoteric, someone who is interested in both would just write a bit of glue code to bind the two together I mean, yes, ideally that is what should have happened, but the first editor to actually do that was VSCode, and the protocol it chose is called LSP, so that's where we are.

afdbcreid 5y ago
But it doesn't need to be a protocol, just some API. And VSCode actually does that - I think it doesn't even have LSP builtin (but I may be wrong).
- matklad 4y ago
  You are correct, and this is indeed one of the important facets I try to illuminate. VS Code doesn't support LSP natively, it just exposes a bunch of APIs to provide IDE features. Actual LSP support is implemented as a separate library on top of these API, an adapter pattern in the wild.