4 ms·

I don't think the author is quite saying "this is wrong". It seems like he's more saying "this is an oversimplification, and the reality is a more-nuanced vers

I don't think the author is quite saying "this is wrong". It seems like he's more saying "this is an oversimplification, and the reality is a more-nuanced version of that statement" -- specifically, that rather than "now languages just build a language server, and editors just accept LSP", it's that "now languages just build a language server, and editors just accept LSP, plus a bit of LSP-specific configuration to point the editor at the particular LSP for a context." Breaking things down a bit further, there are three scenarios discussed in the article: 1. M × N -- every language needs a from-scratch, bespoke plugin for every editor 2. M + N -- the "standard explanation" for LSP, where you build one LSP client implementation per editor, one LSP server implementation per language, and you're done 3. The reality of what exists today: one LSP server implementation per language, one LSP client implementation per editor, and a tiny bit of (usually-end-user-supplied) configuration in your editor to glue those two sides together. The key difference between scenario 1 and scenario 3 is that scenario 1 requires someone with _very deep_ knowledge of a language's structure and semantics to implement a fully-fledged plugin for _every_ editor, usually requiring deep knowledge of that editor (or vice-versa), where scenario 3 allows both ends to wrap that deep knowledge up behind a standardized interface so that any shmuck can write like <100 lines of lua to glue the two ends together (speaking from my own experience as an "any shmuck" using neovim)

aidenn0 4y ago
From TFA: > I believe that this standard explanation of LSP popularity is wrong. In this post, I suggest an alternative picture. If the intent was not to say "this is wrong" that's a very strange way to start your article. The point of TFA (which is wrong, IMO) is that the M × N explanation was wrong, and the evidence for this is: 1. The LSP implementation itself is trivial compared to the work to get all the information the LSP needs. 2. Outside of dedicated IDEs, nobody implemented the "get all the information LSP needs" before LSP existed 3. GP editors didn't implement the high-level protocols necessary for being a good IDE; a big advantage of LSP for the editor side is that the LSP client can include its own implementation of these high-level protocols. One example of such high-level protocols is code completion. 4. If the standard (quadratic complexity) argument were true, we would have had a world where some GP editors were very good for developing some languages My rebuttal: 1. Quadratic growth trumps any small constant-factor 2. To the extent that this is true, it's driven by the quadratic growth of M × N. Efforts to implement this get divided between many different groups. Even something as simple as ctags got both a VIM and Emacs implementation 3. As others in HN comments have pointed out, this isn't universally true, and where it is true, the editor communities tended to settle on one plugin that implements these protocols well before LSP existed. 4. I can think of at least two places where this was true: Emacs for Lisp; Vim for C (particularly with cscope, which gives you completion, cross-references, &c.). Nothing was good for C++, but as TFA notes, C++ essentially requires using the full compiler, and prior to libclang supporting C++ there was no Free tool for doing this (Many people tried with GCC, but got burned by the internal frontend API changing so damn often). That there weren't good Free tools for working with C# is kind of ... expected?
- kps 4y ago
  mlcscope was decent for early C++. I still miss cscope's ability to distinguish between reading and writing.

aidenn0 4y ago

From TFA: > I believe that this standard explanation of LSP popularity is wrong. In this post, I suggest an alternative picture. If the intent was not to say "this is wrong" that's a very strange way to start your article. The point of TFA (which is wrong, IMO) is that the M × N explanation was wrong, and the evidence for this is: 1. The LSP implementation itself is trivial compared to the work to get all the information the LSP needs. 2. Outside of dedicated IDEs, nobody implemented the "get all the information LSP needs" before LSP existed 3. GP editors didn't implement the high-level protocols necessary for being a good IDE; a big advantage of LSP for the editor side is that the LSP client can include its own implementation of these high-level protocols. One example of such high-level protocols is code completion. 4. If the standard (quadratic complexity) argument were true, we would have had a world where some GP editors were very good for developing some languages My rebuttal: 1. Quadratic growth trumps any small constant-factor 2. To the extent that this is true, it's driven by the quadratic growth of M × N. Efforts to implement this get divided between many different groups. Even something as simple as ctags got both a VIM and Emacs implementation 3. As others in HN comments have pointed out, this isn't universally true, and where it is true, the editor communities tended to settle on one plugin that implements these protocols well before LSP existed. 4. I can think of at least two places where this was true: Emacs for Lisp; Vim for C (particularly with cscope, which gives you completion, cross-references, &c.). Nothing was good for C++, but as TFA notes, C++ essentially requires using the full compiler, and prior to libclang supporting C++ there was no Free tool for doing this (Many people tried with GCC, but got burned by the internal frontend API changing so damn often). That there weren't good Free tools for working with C# is kind of ... expected?

kps 4y ago
mlcscope was decent for early C++. I still miss cscope's ability to distinguish between reading and writing.