Comment by modernerd
1 year ago
I work with two types of LSP/LLM-averse programmers:
1. The HLSP user
This group does use an LSP, it turns out, only via you as the conduit: you are their Human Language Server Protocol. They'll ask, ‘can we pair today?’. From that point, navigating code, looking up method names and signatures, and flagging syntax errors before runtime or compile time is your job. How they find their way around when you're not there is unclear, but it's likely slower.
2. I am one with the machine
This crowd has been wrangling code long before IDEs, LSPs and LLMs. They've amassed a terrifying arsenal of tools to find files and references, bulk-rename, pull up docs, and twiddle bits in ways that looks fluent and natural enough when _they_ do it but would take months or years for you to learn if you didn't give up and go back to your IDE. When you ask them _how_ they just did something, they either pull up a short page of Elisp and say, "it's really quite simple we just reverse the node tree and iterate over the folded quarkenspace", or — if they're a vim user — say something like, "oh, that's just the hiboscus plugin, but piped through smark".
So the response to "how do you do it?" seems to be broadly summed up as, "the way we've always done it".
Group 2 isn't necessarily _better_ than LSP/autocomplete/heavy LLM users (people who are very proficient with more modern tools can look like magicians too). The LLM-free crowd were just forced early to become proficient, they've gotten very good with their home-rolled methods, and — in many cases — they probably wouldn't benefit that much from LSPs, or they use them but with features that bug them switched off.
Group 1 would probably better be served by an LSP but either don't believe in the benefits or is just comfortable with their current setup and feels no pressure to change.
I might be in group 2, rely heavily on command line tools and vim to do what vscode and a load of plugins provides younger programmers.
My answer to the fairly common question of "how do you do it" is always the same though.
I always relay that it's taken an evolving 20 year career to learn all that voodoo, I never imply it's simple to gain that knowledge nor do I encourage others to change their working patterns to match mine. I do like showing off a few tricks though!
One thing I do always mention though is the longevity of vim + the command line. I went through a period of swapping IDEs like most junior devs, now I have a setup that I feel can last me till retirement and I can just continually invest in learning to use the same tools better
I've been coding since the 70s . using a modern IDE or VSCode has nothing to do with age
No that's not my point. Becoming very proficient at vim or knowing you way in depth around the command line takes time, years in my experience.
Maybe with 50+ years there's a limited amount left to learn, but with my 25 I'm still picking things up regularly.
So it's usually more junior and less experienced developers who ask "how do you do that" - sometimes with wonder, sometimes genuine confusion.
My answer is never "it's simple" or "it's just" but always something along the lines of "it's a culmination of using the same tools consistently for many years", usually followed by "hey have you seen this trick too".
> This group does use an LSP, it turns out, only via you as the conduit
Oh man, it makes my blood boil when someone asks in which file the function lives, and I know they have a "go to symbol" in their editor of choice, but somehow they never want to learn some features of their tools. I did notice that how you use your tools changes how the project is structured. Neatly organized files and directories are a must if you are not comfortable with quickly jumping to a symbol.
[dead]
It's weird to me that you group LLMs in with code analysis based LSP autocompleters.
Normal autocomplete is basically a context-aware AST browser. It lets you navigate the program semantically instead of file-based.
LLMs are token predictors.
The parent did the same, but of course they're different. The spirit of the question seemed to bundle LSP/autocomplete/LLMs under tooling that some do without.
The way I use LLMs a lot of the time is to simply let copilot complete the method parameters that I was already planning on typing or autocompleting the fields of a struct. It's barely a step over LSP/autocomplete tools but because LLMs have access to more context and aren't restricted by the things they can autocomplete, they work in more scenarios. LLMs get things wrong occasionally but it's usually easy to catch and LSPs can fix those errors.
Very well summarised
Is it though? It reads to me more like elitism to me.
A better summary is: “people have different workflows because different people like to approach problems differently.”
That’s all it is.
I find LSPs largely get in my way. I don’t have them disabled because 1% of the time I do find them useful. But for the other 99% of the time they’re adding no value at all. So I could very easily write code without an LSP (and often do write code in vi with zero additional plugins installed).
What I do really value is code formatters. I like not having to write tidy code and then having code formatters clean it up when I hit save. That’s the kind of enhancement I value. (It also gives me piece of mind that a file has saved successfully when you see alignment pop into place).
> people have different workflows because different people like to approach problems differently.
But the way you like to approach problems is heavily influenced by your history of solving them, what tools were available at the time, what you chose to adopt, and how often you revise that toolset.
It's not elitist to say that people tend to use what they've always used, which was my point: "how do people cope without LSP/LLMs?" tends to be "the way they've always coped" — efficiently or otherwise.
And it tends to track with when you began programming or using specific tools. A vim user who adopted vim in the '90s is more likely to have a light config than those who adopted it more recently, where I see heavy plugin and plugin manager use, LSP integration, pre-configured distros, and Lua-based configs.
1 reply →
LSP enables you to program as you go along, without ever understanding the structure of the whole program. If you don't want to use an LSP you pretty much must understand the whole program you are adding code to
As wikipedia likes to say, quotation needed.
If anything, code-aware tools let you learn the structure of the whole program quicker because you can quickly drill into and explore any arbitrary part of your program (and libraries)