5 ms·

It's concerning to me that the LSP idea is .. a thing. Casey Muratori observed years ago that it's just a way worse way of doing libraries. Like, you're intro

It's concerning to me that the LSP idea is .. a thing. Casey Muratori observed years ago that it's just a way worse way of doing libraries. Like, you're introducing HTTP where there could just be a function call into a DLL/SO. What's the benefit there? Just make vim/emacs/$editor speak some native protocol and be done with it. Then you GUI is just welded directly into the running editor process.. right?? There's no security risk there that wasn't present before as far as I can tell because you were already planning on running the LSP on your local machine..

ukuina 1y ago
You're going to love MCP.
- whattheheckheck 1y ago
  What is up with mcp... feels like CORBA
  - disqard 1y ago
    It's like if CORBA and COBOL had a baby :P Seriously though, it does combine the "RPC IDL" aspect of the former, with the "Use English" aspect of the latter.
chamomeal 1y ago
I’ve definitely wondered about this. Like why does the language-understanding standard have to be a server specifically? Just cause it’s a good architecture to build around? I think I’ve heard that vscode has benefitted hugely from it starting out with a client-server architecture from the start, since it started as a browser based editor. Things like editing code directly on servers via ssh or in containers is easy for vscode cause its client-server all the way down. Vscode and LSP are both Microsoft products, maybe Microsoft has been pushing the client server thing?
- jesse__ 1y ago
  > I’ve definitely wondered about this. Like why does the language-understanding standard have to be a server specifically? I don't think it does. I think it's a bad architectural decision that web bros thought sounded cute. > Things like editing code directly on servers via ssh or in containers I mean, vim and emacs have supported editing over ssh for like .. longer than I've been alive probably. > I think I’ve heard that vscode has benefitted hugely from [clinet-server architecture] IMO VSCode is a giant steaming pile; I'm not sure what the huge benefits could have been. It's intolerably slow, uses an insane amount of system resources, and the debugger barely works most of the time.
dodomodo 1y ago
there are many practical benefits: 1. naturally async 2. each server and the editor itself can be written in its own language and runtime easily 3. servers can just crash or be killed because of oom errors and your editor won't be affected 4. in a lot of languages it is easier to write a server then to call/export c abi 5. the editor can run in a browser and connect to a remote server 6. you can have a remote central server all of those things are done in practice
- jesse__ 1y ago
  IMO, many of these are marginal or nonce gains for the huge cost of introducing a network call in the middle of your program. 1. There's nothing stopping you from shoving the library code onto a thread. For something like this request-response style usage pattern, that sounds extremely straight-forward, especially since the previous paradigm was probably an async server anyways. The calling code (from the editor) obviously already had to be support async calls, so no real change there. 2. If $LANGUAGE can be used to write a server, it should be able to build a DLL. I realize this is not practically true, but I also don't support the notion that we should be writing even light systems stuff like this in JS or python. 3. lol. You're telling me you're worried about a process eating 32GB of ram parsing text files ..? If some core part of my editing workflow is crashing or running out of memory, it's going to be a disruptive enough event that my editor might as well just crash. The program I'm working on uses a lot of memory, my editor better not. 4. I guess ..? Barely seems like that's worth mentioning because .. counterpoint, debugging networked, multi-process programs is massively harder than debugging a singular process. 5. Why would I want (other than extremely niche applications, shadertoy comes to mind) an editor to run in a browser? If I have a browser, I can run an editor that connects to a remote machine. Furthermore, the `library-over-http` approach of LSPs doesn't really buy you anything in this scenario that using a single process wouldn't.. you can just send all the symbol information to the browser.. it's just not that big. 6. Wut?
  - dodomodo 1y ago
    1. True, but in practice it's not always the case, for example older versions of resharper sometimes slowed down typing speed. It's much harder to fuck it up when there is a network request in the middle. 2. What about languages like Java and Go? 3. a. The experience of lsp server crashing is much better than an editor crashing, the editor usually automatically restart it. I had lsp servers crash without me noticing at all. b. Memory problems in both lsp servers and traditional IDE analysis are extremely common in my experience. It seem to me that the problem is that there are a lot of pathological cases where the analysis enters a loop and keeps allocating memory. 4. When mixing runtimes I actually find it easier to have multiple processes because I can attach a specialized debugger to each process but this is definitely an important point. 5. good counter argument, I retract my point 6. what I meant is that for very large code bases it can be beneficial to run a central lsp server that many people can connect to because most of the index is shared between all of them and the parsing+indexing itself is very costly. I heard Google were doing something like that but I don't have more information.

ukuina 1y ago

You're going to love MCP.

whattheheckheck 1y ago
What is up with mcp... feels like CORBA
- disqard 1y ago
  It's like if CORBA and COBOL had a baby :P Seriously though, it does combine the "RPC IDL" aspect of the former, with the "Use English" aspect of the latter.

chamomeal 1y ago

I’ve definitely wondered about this. Like why does the language-understanding standard have to be a server specifically? Just cause it’s a good architecture to build around? I think I’ve heard that vscode has benefitted hugely from it starting out with a client-server architecture from the start, since it started as a browser based editor. Things like editing code directly on servers via ssh or in containers is easy for vscode cause its client-server all the way down. Vscode and LSP are both Microsoft products, maybe Microsoft has been pushing the client server thing?

jesse__ 1y ago
> I’ve definitely wondered about this. Like why does the language-understanding standard have to be a server specifically? I don't think it does. I think it's a bad architectural decision that web bros thought sounded cute. > Things like editing code directly on servers via ssh or in containers I mean, vim and emacs have supported editing over ssh for like .. longer than I've been alive probably. > I think I’ve heard that vscode has benefitted hugely from [clinet-server architecture] IMO VSCode is a giant steaming pile; I'm not sure what the huge benefits could have been. It's intolerably slow, uses an insane amount of system resources, and the debugger barely works most of the time.

dodomodo 1y ago

there are many practical benefits: 1. naturally async 2. each server and the editor itself can be written in its own language and runtime easily 3. servers can just crash or be killed because of oom errors and your editor won't be affected 4. in a lot of languages it is easier to write a server then to call/export c abi 5. the editor can run in a browser and connect to a remote server 6. you can have a remote central server all of those things are done in practice

jesse__ 1y ago
IMO, many of these are marginal or nonce gains for the huge cost of introducing a network call in the middle of your program. 1. There's nothing stopping you from shoving the library code onto a thread. For something like this request-response style usage pattern, that sounds extremely straight-forward, especially since the previous paradigm was probably an async server anyways. The calling code (from the editor) obviously already had to be support async calls, so no real change there. 2. If $LANGUAGE can be used to write a server, it should be able to build a DLL. I realize this is not practically true, but I also don't support the notion that we should be writing even light systems stuff like this in JS or python. 3. lol. You're telling me you're worried about a process eating 32GB of ram parsing text files ..? If some core part of my editing workflow is crashing or running out of memory, it's going to be a disruptive enough event that my editor might as well just crash. The program I'm working on uses a lot of memory, my editor better not. 4. I guess ..? Barely seems like that's worth mentioning because .. counterpoint, debugging networked, multi-process programs is massively harder than debugging a singular process. 5. Why would I want (other than extremely niche applications, shadertoy comes to mind) an editor to run in a browser? If I have a browser, I can run an editor that connects to a remote machine. Furthermore, the `library-over-http` approach of LSPs doesn't really buy you anything in this scenario that using a single process wouldn't.. you can just send all the symbol information to the browser.. it's just not that big. 6. Wut?
- dodomodo 1y ago
  1. True, but in practice it's not always the case, for example older versions of resharper sometimes slowed down typing speed. It's much harder to fuck it up when there is a network request in the middle. 2. What about languages like Java and Go? 3. a. The experience of lsp server crashing is much better than an editor crashing, the editor usually automatically restart it. I had lsp servers crash without me noticing at all. b. Memory problems in both lsp servers and traditional IDE analysis are extremely common in my experience. It seem to me that the problem is that there are a lot of pathological cases where the analysis enters a loop and keeps allocating memory. 4. When mixing runtimes I actually find it easier to have multiple processes because I can attach a specialized debugger to each process but this is definitely an important point. 5. good counter argument, I retract my point 6. what I meant is that for very large code bases it can be beneficial to run a central lsp server that many people can connect to because most of the index is shared between all of them and the parsing+indexing itself is very costly. I heard Google were doing something like that but I don't have more information.