Hacker News Reader

Comment by _verandaguy | Hacker News Reader

While this comment is overly general (some major editors ship without LSP support built in; many more do not have a sane configuration out-of-the-box), it is useful to learn about them and how your editor of choice integrates with them.

The landscape isn't generally intuitive, unfortunately, and while it's getting better, understanding the differences and interop places between LSP, Treesitter, DAP, your editor, and the underlying language-specific tooling can be a big, confusing time hog.

That said, and to be clear: LSP's been a huge boon for me. I used a minimal, kinda-broken configuration for a while with Python, then rebuilt the whole thing when I switched to Rust for work, and holy hell, this thing's awesome.

View on HN

This is way too equivocating.

You are a craftsman, learn your tools. Could you imagine the equivalent from other professionals? A machinist saying, "Understanding the differences and interop places between the DRO, hand controls, and CNC controls for the lathe can be a big confusing time hog."

It takes a couple of hours, and it's a tool you use every single day. Learning how it works is the price of entry, not a mountain to overcome.

It is a fact that some useful things in the software world are a pain in the ass to learn, and that they could be better on that front.

LSP is one of those things, or at least it has been, for a while.

LSP is also something that's not necessary to writing quality code; it's absolutely a major quality-of-life boost, but before rewriting my configs after switching to Rust, my LSP usage was limited to being a slightly faster autocomplete engine more than anything. I didn't have keybinds set up for going to definitions, implementations, or references of symbols. I still put out what I think was decent code. I'm also better off now that I've adopted a more useful config.

IMO it's an important part of this industry (among others) to let developers have whatever workflow they want, within reason. If someone decides they want to invest the time into setting up LSP with their editor, that's their prerogative. If not, that's fine too. I don't know who among my present or past coworkers use LSP outside of occasionally chatting about editor configs with one or two of them, because they've usually figured out a workflow that lets them produce respectable code, and I've never had to question their tooling before questioning their methodology.

The context is a user adopting an editor that has LSP integration and is relying on the language server. That's why I said "it's a tool you use every single day".

If your tool is TextMate, you should learn how TextMate grammars work. If your tool is vi, you should learn how modal editing works. If your tool is Ed, you don't need to learn anything because "Ed is the standard text editor".[1]

[1]: https://www.gnu.org/fun/jokes/ed-msg.html

To be fair, vi has got its dose of "modal editing is difficult to learn" criticism for years. Why shouldn't zed receive the same treatment if configuring LSP is a pain point for many newcomers?

Because the bar is low and part of the craftsman's job is to learn their tools. If everyone who wanted to use a computer needed to learn how language servers work, that would be a problem.

A programmer having to learn how language servers work isn't a pain point, it's their job. It takes a couple hours to learn. A couple hours to learn how to do part of your job isn't notable. Complaining about learning how to do one's job makes one unqualified.

lol ok but where does it stop?

I got into programming long before LSPs and MCPs.

The only craftsmen are the ones at the edge of the lingo tree?

To use your own analogy, as a machinist myself : I can master the concept of the lathe and bow drill without learning simulation-driven CAM, and I would be no less a machinist than the guy pressing buttons on a brand new Haas.

If you work via notepad.exe and assembly with a compiler and linker ready in the next window, fine! the work is what matters.

It stops at the tools you use, "it's a tool you use every single day". If it's not a tool you use every day, you don't need to learn it.

If you don't use language servers, you don't engage with development environments which rely on them, you need not learn them.

If you're making chips on a Monarch 60 you don't need to learn shit about CNC. If you're pushing buttons on a Haas you do.

If you're coming from a Monarch and want to try pushing buttons on the Haas on the kids are using, you need to learn how CNC works. That's your job. If you want to switch from notepad to Zed, you need to learn how language servers work.

> If you want to switch from notepad to Zed, you need to learn how language servers work.

Can you not use Zed without knowing how language servers work?

If you do not understand how the underlying language server is configured, what the input and outputs are, how it operates, you will run into errors you are unequipped to deal with.

Some languages are more severe than others on this. For example, in C++ your editor is not going to be able to make efficient use of the clangd language server without intervention from the programmer to understand and configure it. On the other hand, for Python the Pyright LS will be mostly fine without additional configuration.

What's so special about clangd?

I only had to silence a couple of unneeded warnings specific to codebase I was working with, which took under five minutes and that only because I finally got annoyed enough. Otherwise it took zero configuration (this was Kate though, but it doesn't matter, there is no clangd-specific default config there).

Basically that clangd needs an accurate compilation database to consume, which isn't a requirement for other language spaces.

What is an "accurate compilation database"?

If you mean that dependencies better resolve = project better be in a mostly buildable state or they complain of undefined stuff that's true.

The compilation database[1] given to clangd needs to be complete, understood by the clangd argument parser, and capable of producing a build.

This starts to hurt bad when the compiler producing the build is not clang. If you try to use a compile database describing C++20 module compile lines for GCC, clangd will choke badly. If you're using MSVC flags that clang-cl hasn't been taught yet, clangd falls over. If you're using CMake to produce the compile database, it will leave out synthetic targets from the database and you will see errors because clangd cannot find the interfaces described by those targets. If you're not using CMake you need to configure bear or ninja or whatever to produce a compilation database for you. Etc, etc.

[1]: https://clang.llvm.org/docs/JSONCompilationDatabase.html

https://notepadexe.com/

Every day we stray further from God.

Satire is dead

Except these days companies are telling you to not be a craftsman but a supervisor.

I want to be a craftsman and know my tools and want to actually enjoy using them, but it's becoming less accepted to do so.

Reply on news.ycombinator.com