Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How LSP could have been better

matklad.github.io

Post reply on HN
Print view View original

101–110 of 229 posts

Re: How LSP could have been better

#101

Post by kohlerm »

moring wrote: post #48
mardifoufs wrote: post #31

Earlier quoted context omitted.

I don't get his point? It basically amounts to "nuh uh, this is just bloat". >What type is this value?" Well, they say the way you should do that is—you know, you have your editor and then it's a hassle to make plugins. This is the made-up problem Ok so it's just a made up problem? Like, the "plug in" part or the need for having tooltips/completion etc? If he was referring to the perceived need of a plugin (vs. a mor…

He's saying (without saying it) that LSP is another instance of the "microservices everywhere" hype, and bad for the same reasons -- you have a problem, you try to solve it with a distributed system, now you have two problems and one of them is a set of microproblems. I don't think he is arguing against a standardized interface to language-specific logic, but arguing for that standard to be a library interface, not a…

The reason is probably that dependency management gets much easier (or at least can get much easier). E.g. using any module in VSCode that requires native code (sqlite, treesitter etc) will have to work with that specific version of NodeJs for theat specific Electron version. Also quite a few languages already got implementations of parsers in their native language, porting them over would be a big effort.

Re: How LSP could have been better

#102

Post by rayuela »

jesperlang wrote: post #99
fiddlerwoaroof wrote: post #12

The way a language server should work, imo, is it holds all the code and serves projections of the code on the fly to the editor. The user of the editor makes changes to the code and commits it back, at which point the language server parses the code and integrates it into the codebase, pretty-printing it to files as necessary for source control. But, the file layout should be an implementation detail that the editor…

Exactly! There is such a shift in paradigm that needs to happen here and the only project I know of that is moving in this direction is Unison. I don't want to edit a "file", I want to edit these two functions that exist in some module(s), why can't I just see those two? I constantly jump between many different languages and the cognitive load is noticeable: was it "!=", "/=" or "~="? Why am I writing/viewing ascii a…

This browser AST viewer sounds pretty neat. Mind sharing a link to your repo of it?

Re: How LSP could have been better

#103

Post by matklad »

kmarc wrote: post #94
grumpyprole wrote: post #75

The biggest problem with LSP is that it's a lowest common denominator solution. If I try to edit OCaml using an LSP solution, I don't get features like "query type of symbol", presumably because JavaScript doesn't need it.

It's not a problem, in contrary it is good that implementors are pointed to possible code intelligence features that they current IDE's don't provide either. I read some factual inaccuracies here. LSP (the protocol)'s main driving force was for a long time TypeScript rather than JS. FYI TypesSript has a stronger type system than Java at this point, and it's LSP server is the most comprehensive and supported way to wr…

Agree this is not a problem. rust-analyzer also includes a boatload of custom extensions. Here's how "query type of the selected expression" works, for example:

https://github.com/rust-lang/rust-analyzer/blob/master/docs/...

Re: How LSP could have been better

#104

Post by matklad »

bumbledraven wrote: post #25

Jonathan Blow criticized the performance and complexity of LSP in his talk at DevGAMM 2019 titled "Preventing the Collapse of Civilization" (timestamp 42m26s; https://youtu.be/pW-SOdj4Kkk?t=2546 ): > In the programming language world, there's this thing called Language Server Protocol that is pretty much the worst thing I've ever heard of. There are proponents of this all over, building systems for it right now that…

There's some truth to this! I strongly encourage to architect language servers as libraries first and foremost, with LSP being a relatively thin layer on top of protocol-agnostic library, and only _one_ of the ways to consume the results of the analysis.

At the same time, libraries, sadly, do not actually exist. I can not easily cook up an `.so` and then hook that up with Emacs, Vim, VS Code, and Helix. Moreover, any crash in an `.so` library brings down the whole process, which isn't a good idea for an IDE.

Maybe several years in the future we get an actually good implementation of libraries (I have high hopes for WebAssembly component model), but until then, text-over-stdio can actually be better in practice for some use-cases!

Re: How LSP could have been better

#105

Post by gpderetta »

raincole wrote: post #7

Recently I stumbled upon this issue: https://github.com/joaotavora/eglot/discussions/1127 I don't know enough about emacs and LSP to see the full picture, but it seems that both eglot's and corfu's maintainers, assumably very competent programmers, can't find a solution for this. I only skimmed the thread. My understanding is that LSP dumps a long list of completion candidates at once and they can't decide a cache st…

I read the almost the whole thread and it does not seem to be an LSP issue. As far as I can tell, the issue is purely corfu and eglot disagreeing about the semantics of internal emacs completion hooks they use to communicate and whether corfu should cache on its side or should rely on eglot. Company does not have this impedance mismatch with elgot so it works fine.

Re: How LSP could have been better

#106

Post by gpderetta »

matklad wrote: post #104
bumbledraven wrote: post #25

Jonathan Blow criticized the performance and complexity of LSP in his talk at DevGAMM 2019 titled "Preventing the Collapse of Civilization" (timestamp 42m26s; https://youtu.be/pW-SOdj4Kkk?t=2546 ): > In the programming language world, there's this thing called Language Server Protocol that is pretty much the worst thing I've ever heard of. There are proponents of this all over, building systems for it right now that…

There's some truth to this! I strongly encourage to architect language servers as libraries first and foremost, with LSP being a relatively thin layer on top of protocol-agnostic library, and only _one_ of the ways to consume the results of the analysis. At the same time, libraries, sadly, do not actually exist. I can not easily cook up an `.so` and then hook that up with Emacs, Vim, VS Code, and Helix. Moreover, any…

Yes. LSP is the worst thing in the world. But nothing better exists for this use case, so I'm glad that LSP was invented and I can enjoy working C++ completion, go-to symbol and other nice IDE niceties in emacs.

Re: How LSP could have been better

#107

Post by arp242 »

fiddlerwoaroof wrote: post #56
slimsag wrote: post #34

Earlier quoted context omitted.

That's exactly how LSP is designed. The editor e.g. requests 'the user is hovering over code , what should I show?' and the server responds with some Markdown text. Or 'the user wants to navigate to the thing under their cursor , where should I go?' and the server responds with a file/line. Once you try to use LSP for anything not in that form.. it's not so fun.

No, this is the opposite of how LSP is designed: LSP assumes the editor is looking at a file and this results in a complicated sync dance between editor state and file state. I want the editor to look at temporary buffers served up from the language server and have the code be “written” by sending the temporary buffer back to the language server which handles writing it out to files itself. As far as I know, the only…

I don't use LSP for all the real-time stuff, but I do use it for other things like rename symbol, lookup documentation, jump to, etc. and just "the file you have open" isn't really enough for that in most cases. You need to know about the "file layout" or "complete project" for that sort of thing.

Re: How LSP could have been better

#108

Post by Syzygies »

Wow. There was a tiny typo. I found myself thinking, someone who reasons like this should have a protocol for fixing typos, if they eat their own dog food.

I was floored to see the "fix typo" link at the bottom. Submitted. I now wonder if the typo was on purpose.

Re: How LSP could have been better

#109

Post by gpderetta »

kstrauser wrote: post #52
raincole wrote: post #44

Earlier quoted context omitted.

He is trying to say that LSP should be implemented as a set of libraries (like liblsppython.so). Your editor compiles with these libraries and provide API for plugin authors. It's not unreasonable to expect an editor's developers to know how to link a native library.

That’s the part I vehemently disagree with. There are servers written in a whole lot of languages. I’d bet there are Java servers written in Java. How are you going to link that into an editor written in C? What if the server’s written in Python? A shell script (crazy but legal!)? And even if you solve all of those for C, what if you want to write an editor in Swift. Now you have to implement all those shared library…

Two managed languages will be hard to integrate, but if the library is written in C or in a language with a C ABI, is possible to call it from pretty much any language. The question is whether you would want to run it in the same address space as your editor even if you could. Clang is more stable these days, but I still see clangd crashing from time to time and it would be very annoying if it were to take down my editor every time.

So in the end even if you had the option of running the language plugin within the same address space, probably you wouldn't want to. A better RPC protocol than JSON would be nice, but a standard is better than no standard.

Re: How LSP could have been better

#110

Post by [deleted] »

moring wrote: post #80
jcrites wrote: post #72

Earlier quoted context omitted.

I also think it's a bit overblown to call communication with a locally running process a "distributed system". I mean, that's kind of true, but not really any more true than if you were to call having multiple threads in your process a "distributed system".

It introduces _some_ of the failure modes of a distributed system, like unsynchronized / inconsistent data, but not all, like network failures. I think he does have a point there -- as a user, I should not have to care whether an IDE talks to a library via its API or to a language server via LSP, but here I am, watching WebStorm to act up and complain that the TS language server crashed. One thing that Blow misses IM…

[deleted]
Post reply on HN