4 ms·

I think this post hits the nail on the head. Before LSP, you could google for “$language Vim support” and find some results but more often than not, you were go

by jez 4y ago

I think this post hits the nail on the head. Before LSP, you could google for “$language Vim support” and find some results but more often than not, you were going to get nothing. Once LSP gained popularity, the question shifted to “why doesn’t $language have a language server yet?” which set an easy goal post for languages and compilers to go from 0 to 1 in terms of IDE support.

wodenokoto 4y ago
But isn’t that exactly what he starts of arguing against? The first chart shows that before lsp you needed special language support for each language for each editor, which is unfeasable. After lsp you just need lsp support for each language. The author then goes on to say “this is wrong”
- aaron_m04 4y ago
  Right. My takeaway after reading the whole post was "so it really _is_ M * N after all".
- ubertaco 4y ago
  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.
- tristan957 4y ago
  If you look at Neovim, they provide a built-in LSP client, so you just have to bring your own language server and everything just works. Now there are special extensions like rust-tools.nvim popping up that provide additional support on top of the built-in LSP client or enhance the features of the language server.

by jez 4y ago

wodenokoto 4y ago

But isn’t that exactly what he starts of arguing against? The first chart shows that before lsp you needed special language support for each language for each editor, which is unfeasable. After lsp you just need lsp support for each language. The author then goes on to say “this is wrong”

aaron_m04 4y ago
Right. My takeaway after reading the whole post was "so it really _is_ M * N after all".
ubertaco 4y ago
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.
tristan957 4y ago
If you look at Neovim, they provide a built-in LSP client, so you just have to bring your own language server and everything just works. Now there are special extensions like rust-tools.nvim popping up that provide additional support on top of the built-in LSP client or enhance the features of the language server.