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

191–200 of 229 posts

Re: How LSP could have been better

#191

Post by kstrauser »

BaculumMeumEst wrote: post #187
kstrauser wrote: post #184

Earlier quoted context omitted.

I switched from Emacs to VSCode for a while, but couldn’t stick with it. It’s soooo easy to set up and start using, and it does the right thing 99% of the time. However, that 1% drove me nuts. I don’t remember the specifics, just that there were a few things that bugged the everliving hell out of me, and they couldn’t be changed without doing some significant work inside VSCode itself and then in its extensions. The…

Haha, yes, virtually all of that has been my experience as well, except substituting BBEdit for Sublime. I'm still convinced that just sucking it up and sticking with VS Code is the way to go, I just can't make it stick. But Emacs is still alluring enough that I spent like 4 hours over the last few days trying to get clangd to work in a project that involves cross compiling C++ in a way where generating compile_comma…

My yesterday looked a lot like that. Well, if I can't get BBEdit to work like I'd like, guess it's time to dust off my Emacs config and modernize it. Once more into the breach!

If you figure out how to stop this, please let me know.

Re: How LSP could have been better

#192

Post by kstrauser »

tuukkah wrote: post #190
kstrauser wrote: post #177

Earlier quoted context omitted.

I agree. I primarily use(d) Emacs, and while it’s had good support for certain languages for decades, now it handles younger languages like TypeScript and Rust exactly as well as Microsoft’s editors do. That’s freaking magical.

Microsoft does not use LSP for its own language TypeScript. They have something that works better for VSCode: tsserver. When TypeScript evolves, Microsoft updates tsserver and VSCode as needed. To get the updates to Emacs, someone needs to make the respective changes to a third-party TypeScript LSP first. And it won't work as well because LSP isn't as good.

Ugh, I didn't realize that.

Re: How LSP could have been better

#193

Post by mjw1007 »

throwaway50182 wrote: post #132
prometheon1 wrote: post #129

Earlier quoted context omitted.

What we are seeing now could fit a timeline where Microsoft is doing EEE again, as well as a timeline where Microsoft is trying to change its ways. Building VSCode, LSP and Typescript could still prove to be the Embrace and Extend phase. There are some worrying signs, e.g. many VSCode extensions built by MS don't work on open-source VSCode builds like code-server and VSCodium. From a business perspective, this makes…

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.

Re: How LSP could have been better

#194

Post by Conscat »

spunker540 wrote: post #152
Hendrikto wrote: post #112

Earlier quoted context omitted.

> If I am most comfortable/fluent viewing python, why can't I view a javascript source as python? Because they are not isomorphic. At all. Even if you just consider the languages themselves, and ignore their ecosystems, which, in practice, you cannot.

Some percent of python code I’ve written code be rewritten as JavaScript code at the function-level.

Meta's "Transcoders" or whatever they changed the name to demonstrate that. However, if we want perfectly semantically equivalent functions, as soon as you add two numbers, then Python -> JS is impossible. The best we can do is approximately translate the behavior.

Re: How LSP could have been better

#195

Post by alfalfasprout »

hardware2win wrote: post #134
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…

Visual Studio was a meme? It is still top IDE matched by maybe just JB

I was going to say-- visual studio is phenomenal. The profiler is incredible to use.

Re: How LSP could have been better

#196

Post by fiddlerwoaroof »

vidarh wrote: post #173
crabbone wrote: post #146

Earlier quoted context omitted.

> I don't want to edit a "file", I want to edit these two functions that exist in some module(s) That shift happened like 20 (?) years ago. That's how Eclipse displays your Java stuff. It goes to a great length to pretend that there aren't files. Instead there are packages. Seeing noobies and experienced programmers struggle with it for years, my conclusion is that this is a bad idea. Most problematically it creates…

I agree with all of this. I'd only add that well before Eclipse and its ilk, Java started down this path with the deep filesystem paths that made it painful to work with from the filesystem without the kind of multi-level collapsing Github does. It was a choice that pushed people towards seeing the filesystem hierarchy as a nuisance, and laying the groundwork for encouraging people to obscure it in IDEs.

The problem with the filesystem is that it privileges organization scheme which isn’t the best one for every editing task. This makes, for example, implementation inheritance hard because your class has a bunch of invisible code in it. But, it you could expand all the superclass methods into a single view and then have edits automatically integrated into the appropriate places, this wouldn’t be as much of a problem.

Java’s filesystem hierarchy is a great example of a “fileout” format for the sort of environment I’m talking about. Another example here is smalltalk repositories generated by Iceberg: https://github.com/pharo-vcs/iceberg

Re: How LSP could have been better

#197

Post by fiddlerwoaroof »

crabbone wrote: post #146
jesperlang wrote: post #99

Earlier quoted context omitted.

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…

> I don't want to edit a "file", I want to edit these two functions that exist in some module(s) That shift happened like 20 (?) years ago. That's how Eclipse displays your Java stuff. It goes to a great length to pretend that there aren't files. Instead there are packages. Seeing noobies and experienced programmers struggle with it for years, my conclusion is that this is a bad idea. Most problematically it creates…

> Seeing noobies and experienced programmers struggle with it for years, my conclusion is that this is a bad idea. Most problematically it creates "programmers" who have no idea how their project is actually organized

The layout of files on a filesystem is not how a project is organized. The organization of a typical project is a graph that’s lossily represented by filesystem trees.

Re: How LSP could have been better

#198

Post by fiddlerwoaroof »

pawelmurias wrote: post #165
fiddlerwoaroof wrote: post #86

Earlier quoted context omitted.

I want a system more like Bank Python[1] or Unison[2] or Pharo Smalltalk[3] that gets us beyond the idea of "code in files". And I have plans to build this on top of Common Lisp + SLIME [1]: https://calpaterson.com/bank-python.html [2]: https://www.unison-lang.org [3]: https://pharo.org

Loads of people absolutely hate having to use a weird custom IDE just to try a language. That's why all the smalltalk like things are doomed for failure unless they are enforced by a platform.

Yeah, this is the problem my proposal solves.

Re: How LSP could have been better

#199

Post by fiddlerwoaroof »

NoGravitas wrote: post #174
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…

That's basically a subset of image-based development, as seen in Smalltalk and Lisp since forever.

Yes, and I write a lot of lisp

Re: How LSP could have been better

#200

Post by nerdix »

I've always found it interesting that MS basically started LSP but C# has probably the worst LSP implementation I've ever seen. It's flat out broken.

Rust, Go, Dart, etc all vastly superior. I recently opened up a powershell script in nvim and even powershell's LSP is better.

I guess there is a new C# LSP with C# Dev Kit and it seems better in vs code but I haven't tried to use it with nvim yet.

Post reply on HN