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

211–220 of 229 posts

Re: How LSP could have been better

#211

Post by fiddlerwoaroof »

Hendrikto wrote: post #112
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…

> 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.

I think this is a bit too simplistic of a take: there’s no reason you couldn’t have multiple syntaxes for the same AST so that people could work in the syntax they prefer (e.g. C-style, Pascal style, Indentation-sensitive, S-expressions). Textual syntax can be implemented a layer up, if the input to the interpreter/compiler is not text but a data structure. (The true meaning of what people think is the benefit of “homoiconicity”: eval consumes and produces the same types of data)

Re: How LSP could have been better

#212

Post by kstrauser »

smacke wrote: post #201
kstrauser wrote: post #68

Earlier quoted context omitted.

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...)

That happens. I’m kind of bummed at the situation in general, but no one owes me to prioritize my convenience over theirs.

Re: How LSP could have been better

#213

Post by ww520 »

misja111 wrote: post #118
ww520 wrote: post #51

Earlier quoted context omitted.

LSP stands for Language Server Protocol. It's a communication protocol between the clients (text editors, debuggers, source viewers, etc) and the language servers. Typically a language compiler runs over the source files and terminates once it's done. All the compilation states are gone. The language server is the compiler itself running for a long time; its aim is to maintain the compiled states of the source files…

Thanks for the very clear explanation! Where does the language server typically run? Does it run on some remote server or as a separate process next to your editor on your local machine?

The language server typically runs in another process alongside of the editor on the same machine. Usually it is the editor that spawns off a new process of the language server and connects to it. The editor can launches multiple language servers, one per a project of a particular language.

E.g. when the editor opens a Rust file, it would launch the Rust language server and connects to it. When it opens a Javascript file, it would launch the Javascript language server and connects to it.

Running the language server remotely would require more setup. The editor and the language server need to look at the same file, so you have to sync the changes to the file locally and remotely somehow. Also the editor might not be able to automatically launch a remote language server. You have to start it manually and make the editor connect to it manually. It's just not a smooth UX.

Re: How LSP could have been better

#214

Post by ww520 »

DiabloD3 wrote: post #119
ww520 wrote: post #51

Earlier quoted context omitted.

LSP stands for Language Server Protocol. It's a communication protocol between the clients (text editors, debuggers, source viewers, etc) and the language servers. Typically a language compiler runs over the source files and terminates once it's done. All the compilation states are gone. The language server is the compiler itself running for a long time; its aim is to maintain the compiled states of the source files…

> debuggers That's where the sibling protocol, DAP, comes in. Rest of this is a good simple explanation on what LSP does, otherwise.

Yes, DAP is another protocol for remote debugging. I was thinking for debuggers that can already debug locally but want to show type info or various definition of entities in the source code.

Re: How LSP could have been better

#215

Post by Calavar »

fiddlerwoaroof wrote: post #211
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.

I think this is a bit too simplistic of a take: there’s no reason you couldn’t have multiple syntaxes for the same AST so that people could work in the syntax they prefer (e.g. C-style, Pascal style, Indentation-sensitive, S-expressions). Textual syntax can be implemented a layer up, if the input to the interpreter/compiler is not text but a data structure. (The true meaning of what people think is the benefit of “ho…

Sure, you could do that. But how does it help you understand the code better than reading it in the original source form? Programming languages are more than syntax. If you don't understand the semantics, you don't understand the code.

Re: How LSP could have been better

#216

Post by fiddlerwoaroof »

Calavar wrote: post #215
fiddlerwoaroof wrote: post #211

Earlier quoted context omitted.

I think this is a bit too simplistic of a take: there’s no reason you couldn’t have multiple syntaxes for the same AST so that people could work in the syntax they prefer (e.g. C-style, Pascal style, Indentation-sensitive, S-expressions). Textual syntax can be implemented a layer up, if the input to the interpreter/compiler is not text but a data structure. (The true meaning of what people think is the benefit of “ho…

Sure, you could do that. But how does it help you understand the code better than reading it in the original source form? Programming languages are more than syntax. If you don't understand the semantics, you don't understand the code.

Different syntaxes are better for different purposes: s-expressions are easy to manipulate structurally; significant indentation is often easier to read; etc. Semantics is important, but syntactic noise is too.

Re: How LSP could have been better

#217

Post by Hendrikto »

fiddlerwoaroof wrote: post #211
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.

I think this is a bit too simplistic of a take: there’s no reason you couldn’t have multiple syntaxes for the same AST so that people could work in the syntax they prefer (e.g. C-style, Pascal style, Indentation-sensitive, S-expressions). Textual syntax can be implemented a layer up, if the input to the interpreter/compiler is not text but a data structure. (The true meaning of what people think is the benefit of “ho…

> Textual syntax can be implemented a layer up, if the input to the interpreter/compiler is not text but a data structure.

If you designed the languages and interpreters/compilers around it. Neither Python nor Javascript are, though.

Re: How LSP could have been better

#218

Post by vidarh »

fiddlerwoaroof wrote: post #196
vidarh wrote: post #173

Earlier quoted context omitted.

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.…

The thing is, nothing stops you from having alternative views as well, but the moment you make that expected and de-facto privileged by making filesystem nabigation painful, and people stop thinking about how to present the project as a whole in a narrative as a result, you tend to lose structural information that matters when trying to navigate unfamiliar code.

Re: How LSP could have been better

#219

Post by crabbone »

fiddlerwoaroof wrote: post #197
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…

> 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.

What I'm trying to say is that this approach prevents developers from effectively working with the tools their projects rely on to function.

I.e. be it Ant, Maven or Cradle, in order to carry out project-related tasks they will rely on files. They feed files to various tools, create new ones, delete or move old files, and then the deployed project needs to discover those files somewhere and so on.

When a programmer doesn't understand how what they are presented with in their editor maps to whatever any of those tools do you get questions like: "Where is my Java home?" or "I want to debug in the testing environment, can you tell me where is it?" or "I think I've built my program, and I want to patch the existing deployment with the program I've built -- how do I find the program I've built and where is it deployed?". Not to mention more trivial stuff like developers arguing about having / not having access to eg. Protobuf files in their project because someone's editor not having a plugin to open them and they simply don't know how to find their project directory on their computer... or trying to run poorly written Maven build which has some relative paths in it, from a wrong directory.

Re: How LSP could have been better

#220

Post by fiddlerwoaroof »

Hendrikto wrote: post #217
fiddlerwoaroof wrote: post #211

Earlier quoted context omitted.

I think this is a bit too simplistic of a take: there’s no reason you couldn’t have multiple syntaxes for the same AST so that people could work in the syntax they prefer (e.g. C-style, Pascal style, Indentation-sensitive, S-expressions). Textual syntax can be implemented a layer up, if the input to the interpreter/compiler is not text but a data structure. (The true meaning of what people think is the benefit of “ho…

> Textual syntax can be implemented a layer up, if the input to the interpreter/compiler is not text but a data structure. If you designed the languages and interpreters/compilers around it. Neither Python nor Javascript are, though.

My point isn’t that existing languages are designed this way, but it wouldn’t be hard to retrofit this onto an existing language. Especially one like JavaScript that already has relatively widely-used transpilers
Post reply on HN