Hacker News Reader

Comment by diegoperini | Hacker News Reader

> yet the end result was complete shit

Could you elaborate why? It looks like a useful protocol.

I elaborated a bit when I edited my post, but to be more specific, I think LSP is a protocol that fails at its stated goals. Every server is buggy as hell and has its own quirks and behaviors, so editors that implement LSP have to add workarounds for every server, which renders the point of LSP moot. It's the worst of both worlds: editors are still duplicating effort, but with fewer, if any of the benefits of tools tailor-made for a specific editor-language combination. And that's not even touching on the protocol's severe performance issues.

Unsurprisingly, the vast majority of servers work much better with VSCode than other editors. Whether this was a deliberate attempt by Microsoft to EEE their own product, or simply a convenient result of their own incompetence, is ambiguous.

LSP is underspecified for sure. I don't think this is a situation that is limited to LSP though. It happens when software interfaces are underspecified (or post-hoc specified) with a strong dependence on a reference implementation (VSCode in this case) and the absence of a canonical validation test suite.

Exactly the same thing happened with VST audio plugins. Initially Cubase was the reference host, later Ableton Live became the reference and it was impossible to convince plugin developers that they were out of spec because "it works in Ableton".

My impression, having programmed against both the LSP and VST specifications is that defining well-specified interfaces without holes in them is not a common skill. Or perhaps such a spec (maybe ISO C is an example) is too expensive to develop and maintain.

The original blog post links to a critique.

Reply on news.ycombinator.com