LSP: The Good, the Bad, and the Ugly
The author discusses the Language Server Protocol's improvements to IDE tooling, critiques its lack of openness and concurrency issues, and calls for a more collaborative development approach to better serve the community.
Read original article
The article discusses the author's experiences and opinions regarding the Language Server Protocol (LSP) and its implementation through the Haskell Language Server (HLS). The author acknowledges the significant improvements LSP has brought to IDE tooling across various editors, highlighting its omnipresence, decent feature set, and the ease it provides for developers to create language support. However, the author also critiques several aspects of LSP's design, including its lack of openness, as it is primarily managed by a single Microsoft committer, limiting community input. The author points out issues with concurrency handling, causality, and state synchronization, which complicate the protocol's functionality. Despite these criticisms, the author appreciates the protocol's focus on presentation over semantics and its commitment to backward compatibility. The post emphasizes the need for a more open and collaborative approach to LSP's development, akin to other standards like HTTP, to better serve the community's needs.
- The LSP has significantly improved IDE tooling for various programming languages.
- Critiques include a lack of openness and community involvement in LSP's development.
- Issues with concurrency, causality, and state synchronization complicate the protocol's functionality.
- The author appreciates LSP's focus on presentation and backward compatibility.
- A call for a more collaborative approach to LSP's evolution is emphasized.
Related
Lisp macros and read work because of a bug in the original definition of Lisp
M-LISP is a new LISP dialect that integrates operational semantics with metalinguistic features, addressing inconsistencies through eval and reify operators while enhancing the understanding of LISP's semantics and functional programming.
Betting on DSPy for Systems of LLMs
Isaac Miller's blog discusses DSPy, an open-source framework for integrating LLM calls, emphasizing verifiable feedback and real-world metrics, while acknowledging its reliability issues and potential for future improvements.
The official Elixir Language Server team
The Elixir programming language has formed a Language Server team to enhance code intelligence tools, consolidate existing implementations, and seek community support, with funding from Fly.io and Livebook.
Why Does EmacsLisp Suck?
EmacsLisp faces criticism for lacking modern features like lexical scoping and multithreading, relying on global state, and having cumbersome APIs, while users are divided on the need for reform.
The art of programming and why I won't use LLM
The author argues that the effectiveness of large language models in programming is overstated, emphasizing coding as a creative expression and expressing concern over the diminishing joy in programming due to automation.
- Several commenters agree with the article's critique of LSP's openness and the challenges it poses for implementers, particularly regarding configuration and the need for specific extensions.
- There is a discussion about the complexity of the LSP specification, with some arguing that it is manageable compared to other specifications, while others express concerns about its growing size and difficulty for new implementers.
- Some commenters suggest that Microsoft’s interests in promoting their IDEs may hinder the LSP's development and accessibility for the broader community.
- There are calls for a more standardized approach to LSP extensions and a desire for a common format to simplify implementation across different languages.
- The potential for synergies between LSP and other systems, like tree-sitter, is also mentioned as a way to improve language support.
12 commentshttps://matklad.github.io/2022/04/25/why-lsp.html
https://matklad.github.io/2023/10/12/lsp-could-have-been-bet...
The paradox is that it was meant to avoid to write language support for each editor. Yet, if you want to support vscode you must create a specific extension for it and can't just have a language client.
The article mention the configuration problem, but I'd add the problem that Microsoft refuses to specify a way for the server to tell the client what are the config options so that the client can show some kind UI showing the possible configuration options with a description of what they do. https://github.com/microsoft/language-server-protocol/issues...
If LSP isn't truly open, then neither are most GNU projects. It was very common for the first 15+ years of GNU's existence for the public development process of a project to be "the single maintainer publishes a release archive whenever they feel like it"
It's a standard freely published and available for all to implement. If that's not "truly open" then we have moved the goalposts way too far.
I have a maybe wrong and bad opinion that LSP is actually at the wrong level. Right now every language needs to implement a from scratch implementation of their LSP server. These implementations are HUGE and take YEARS to develop. rust-analyzer is over 365,000 lines of code. And every language has their own massive, independent implementation.
When it comes to debugging all native language support common debug symbol formats. PDB for Windows and DWARF for Nixy things. Any compiled language that uses LLVM gets debug symbols and rich debugging "for free".
I think there should be a common Intellisense Database file format for providing LSP or LSP-like capabilities. Ok sure there will still be per-language work to be done to implement the IDB format. But you'd get like 95% of the implementation for free for any LLVM language. And generating a common IDB format should be a lot simpler than implementing a kajillion LSP protocols.
My dream world has a support file that contains: full debug symbols, full source code, and full intellisense data. It should be trivial to debug old binaries with full debugging, source, and intellisense. This world could exist and is within reach!
Given what it does, that’s pretty dang small. You don’t get all those features across every programming language without some complexity.
Compared to the 3,000+ pages specifications I’ve dealt with, this is easy.
I have a very tiny violin and a cricket to play it for anyone complaining about a few hundred pages. :)
I'm not so sure. Maybe it's not the case today, but if the protocol eventually becomes so large, so crufty, so under-specified that implementers struggle to provide their implementations, then users suffer.
Related
Lisp macros and read work because of a bug in the original definition of Lisp
M-LISP is a new LISP dialect that integrates operational semantics with metalinguistic features, addressing inconsistencies through eval and reify operators while enhancing the understanding of LISP's semantics and functional programming.
Betting on DSPy for Systems of LLMs
Isaac Miller's blog discusses DSPy, an open-source framework for integrating LLM calls, emphasizing verifiable feedback and real-world metrics, while acknowledging its reliability issues and potential for future improvements.
The official Elixir Language Server team
The Elixir programming language has formed a Language Server team to enhance code intelligence tools, consolidate existing implementations, and seek community support, with funding from Fly.io and Livebook.
Why Does EmacsLisp Suck?
EmacsLisp faces criticism for lacking modern features like lexical scoping and multithreading, relying on global state, and having cumbersome APIs, while users are divided on the need for reform.
The art of programming and why I won't use LLM
The author argues that the effectiveness of large language models in programming is overstated, emphasizing coding as a creative expression and expressing concern over the diminishing joy in programming due to automation.