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

201–210 of 229 posts

Re: How LSP could have been better

#201

Post by smacke »

kstrauser wrote: post #68
smacke wrote: post #67

Earlier quoted context omitted.

Have you opened an issue against https://github.com/python-lsp/python-lsp-server ? I'm an occasional contributor for easy fixes; if your fix is easy chances are it would get picked up.

I came in at the tail end of https://github.com/python-lsp/python-lsp-server/issues/195 . The possibility of me sponsoring a fix came up, and I’m on board with it, but the other contributor never replied.

Ah yeah, Carlos is very low on cycles (like all of us I guess), probably due to the day job. (If only OSS had competitive pay...)

Re: How LSP could have been better

#202

Post by laurmaedje »

I have a question about the point on highlighting in particular. With a subscription-based model, don't you lose out on the ability to partially highlight a file based on the visible ranges in the editor? Unless you re-subscribe to the highlighting whenever the visible ranges change, the language server wouldn't know which slice(s) of the document to highlight after a change comes in.

Re: How LSP could have been better

#203

Post by schemescape »

schemescape wrote: post #18
dom2 wrote: post #15

One thing that has annoyed me with some personal implementation work is why does DAP use a cosmetically similar but not following spec version of JSONRPC? Why not just use JSONRPC especially considering LSP already does?

I would assume DAP predates (and possibly motivated) JSONRPC (edit: so it might have been working off of a draft spec). Hopefully someone knowledgeable can comment.

Note: This was definitely not correct! JSON-RPC apparently started in 2005.

Re: How LSP could have been better

#204

Post by follower »

throwaway50182 wrote: post #117
junon wrote: post #115

LSP is just Microsoft's EEE[0] into the open source space, as they've done with a number of things (including Typescript and buying GitHub/NPM, WSL, etc). Visual Studio was a meme for a long time because it was so heavy and enterprisey, so to capture more market share they made the cool new shiny version VS Code, and wanted to compete with e.g. Atom whilst still having their grip on the ecosystem as a whole. So LSP w…

What exactly did they embrace and extend with LSP? And what's going to get extinguished? They created it and others adopted it... They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. Instead they took care to make a well documented and reasonably open protocol that others can use for their own language support, and to integrate TypeScript into other IDEs. I…

> They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it.

This was something that had puzzled me for a while until just today when reading another post on the original linked article's site.

It seemed odd that after MS had used Atom/VSCode to essentially "suck all the air out" of the FLOSS/free editor space that they would then "share" something like LSP which seemed to then make it easier for other editors to (at least potentially) offer a similar standard of support for languages that had LSP implementations.

(Because from a purely technical POV I do see LSP as a positive development in the editor space.)

But what I'd apparently missed was something mentioned in an earlier "Why LSP?"[0] post by the same author:

> "[...] Microsoft, who were a vendor of both languages (C# and TypeScript)

> and editors (VS Code and Visual Studio), and who were generally losing

> in the IDE space to a competitor (JetBrains)."

and, so:

> "...launched LSP to increase the value of their platform in other domains

> for free (moving the whole world to a significantly better IDE equilibrium

> as a collateral benefit)."

Thus, assuming this is accurate, the actual target in this case was JetBrains and "sharing" LSP was seen as a reasonable "cost" in order to get additional leverage.

Given that I haven't generally paid attention to any of the C#/TypeScript/JetBrains worlds that was an angle that I'd missed.

The assumption on my part that "sharing" LSP still wasn't likely to be an "altruistic" act on the part of MS was primarily driven by the fact that they hadn't really given up on proprietary/control they'd simply moved the demarcation point to be at the LSP implementation level (e.g. the plugin for Python) & "marketplace" access (e.g. remote plugin) etc (e.g. telemetry).

And by defining/retaining control of LSP they've inserted themselves in the path between other editors & LSP implementations which inherently has value (e.g. by being the "reference"/default implementation[1]).

Anyway, that was an aspect of the context for LSP that I wasn't aware of before today, so thought it might be of interest to some.

(Obviously the majority of today's developers see no issue with the actions of MS in any of this, so, if that's you feel free to agree to disagree & leave the rest of us to tilt at windmills in peace--after all, why would we stop now? :D )

[0] https://matklad.github.io/2022/04/25/why-lsp.html#Why-LSP-is...

[1] Which is one of the reasons I'd really like rust-analyzer to one day change to target an editor implemented in Rust by default. VS Code doesn't need any more value added to it for free but any Rust-based editor would benefit from being a "First Class" rust-analyzer citizen & thus strengthen the wider Rust ecosystem.

Re: How LSP could have been better

#205

Post by School-Cotton »

alexvitkov wrote: post #90
kstrauser wrote: post #52

Earlier quoted context omitted.

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…

Frankly, if your language can't compile a .so/.dll that can interact with the rest of the system in a sane way, use a better language. I used to disagree with Blow on this point, as stdin/stdout communication really has the arguable advantage that you can write your Brainfuck LSP in Brainfuck, but I've spent way more time than I find reasonable over the last few years dealing with the consequences of the LSP model -…

> Frankly, if your language can't compile a .so/.dll that can interact with the rest of the system in a sane way, use a better language.

Feel free to only use languages you personally find aesthetically pure. The rest of us will continue getting work done.

Re: How LSP could have been better

#206

Post by School-Cotton »

alexvitkov wrote: post #93
valcron1000 wrote: post #42

Earlier quoted context omitted.

I don't care how many credentials Jonathan Blow has, this take is pure bs. "we're spending all this time overcomplicating stuff that we used to be able to do in 1960", yet he takes the time to explain "tricks" on how to rename variables [1], while modern tools (not necessarily LSP) let you fly through the code [2]. This is just an "old man rants at cloud" take. 1. https://youtu.be/2J-HIh3kXCQ 2. https://youtu.be/AxxN…

The environments we work in shape our biases and what we find good and bad. Game programmers spend their careers writing C++ where, yes, you really need tricks like this to rename the variable, as the language is so fucking insane that ALL tooling gets it wrong - and the consequences of getting it wrong can be disastrous. The most widely used options for C++ are VS's IntelliSense and clangd. IntelliSense is utter gar…

rust-analyzer renames over LSP are perfect the vast majority of the time. The dichotomy among static languages isn't managed vs. unmanaged, it's C++ vs. not-C++.

Re: How LSP could have been better

#207

Post by junon »

follower wrote: post #204
throwaway50182 wrote: post #117

Earlier quoted context omitted.

What exactly did they embrace and extend with LSP? And what's going to get extinguished? They created it and others adopted it... They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. Instead they took care to make a well documented and reasonably open protocol that others can use for their own language support, and to integrate TypeScript into other IDEs. I…

> They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. This was something that had puzzled me for a while until just today when reading another post on the original linked article's site. It seemed odd that after MS had used Atom/VSCode to essentially "suck all the air out" of the FLOSS/free editor space that they would then "share" something like LSP which…

This is much better put than I could have said.

Re: How LSP could have been better

#208

Post by gilcot »

froh wrote: post #168
BaculumMeumEst wrote: post #144

Earlier quoted context omitted.

you just have a call to (stockholm-syndrome) buried somewhere in your 1200 line init file

(xkcd-get 297) https://xkcd.com/297/ https://github.com/vibhavp/emacs-xkcd

Parenthesis are flying like god's edition… ;D

Re: How LSP could have been better

#209

Post by junon »

Syzygies wrote: post #178
junon wrote: post #113

Earlier quoted context omitted.

This is a strange position to take. "Someone who uses logic and reasoning should churn out pristine, flawless work."

You misunderstand me. I am amazed by the author's attention to robust protocol design. No one wants to be "that person" who observes a missing space before an open parenthesis, so usually smoothing out flawless work is not a collaborative process. I found myself daydreaming how blogs would work if the author turned their brilliant attention to the process of blogging itself. They would solve such a problem, to encour…

Ah I did misunderstand, my mistake :)

Re: How LSP could have been better

#210

Post by throwaway50182 »

mjw1007 wrote: post #193
throwaway50182 wrote: post #132

Earlier quoted context omitted.

By this logic, they are also currently Embracing and Extending Windows, Office, etc. This doesn't make sense to me. It's their original products, not something they embraced and plan on extinguishing.

CSS was to a large extent a Microsoft project (when the time came to introduce stylesheets it was more-or-less Opera and Microsoft against Netscape, and Microsoft had many more users than Opera). Nonetheless Microsoft managed to use CSS to achieve a great deal of user lock-in by refusing to conform to the standard they co-authored.

Well then that's clearly not EEE. There can be more predatory market strategies than just EEE.
Post reply on HN