4 ms·

This is a “correction” of a strawman only: The left diagram is exactly what would have been necessary to achieve the same result. Since that’s clearly infeasibl

This is a “correction” of a strawman only: The left diagram is exactly what would have been necessary to achieve the same result. Since that’s clearly infeasible, most of the arrows didn’t actually exist, and never would have. That was always the point. It’s precisely because the left picture is impractical that something like the LSP was necessary. Somehow, the author misunderstood the original argument, dismissed it, independently discovered the actual argument, and now claims they’re the one who found the true reason for LSP, when in reality, it’s just the standard argument.

afdbcreid 4y ago
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 4y 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 4y 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 4y 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 4y 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 4y 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.
bsder 4y ago
It's really not about the arrows. The benefit of the LSP is that it decoupled the plugin development environment from the editor development environment. This is a BIG deal. Remember building plugins for Eclipse? Exactly. You don't because building them was massive, massive pain. You had to install a universe of build tools, understand how they went together, build your plugin, fit into the UI correctly, pull it into the system and configure it, and finally you could do some development. The existence of the LSP means that the plugin development and the editor development are decoupled. I don't have to put together the enormous build system of the editor in order to create the LSP plugin. I'm not stuck in the language of the editor implementation when creating an LSP plugin. This dropped the cognitive load for creating a plugin by order and orders of magnitude.

afdbcreid 4y ago

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 4y 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 4y 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 4y 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 4y 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 4y 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.

bsder 4y ago

It's really not about the arrows. The benefit of the LSP is that it decoupled the plugin development environment from the editor development environment. This is a BIG deal. Remember building plugins for Eclipse? Exactly. You don't because building them was massive, massive pain. You had to install a universe of build tools, understand how they went together, build your plugin, fit into the UI correctly, pull it into the system and configure it, and finally you could do some development. The existence of the LSP means that the plugin development and the editor development are decoupled. I don't have to put together the enormous build system of the editor in order to create the LSP plugin. I'm not stuck in the language of the editor implementation when creating an LSP plugin. This dropped the cognitive load for creating a plugin by order and orders of magnitude.