I either use Vim in the terminal or VS Code. When I'm in the zone, I'm perfectly fine using either tool and don't think much of it.
But I tend to use vim more often when programming C or bash and way less when I'm in JS context.
Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?
571–580 of 652 posts
Re: Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?
#572I think purism is a slippery slope for experienced people, I too suffer from this to a certaint extent. It's natural to fight change as you get older and it's part of the struggle to change your behavior and adapt to the changing times. Short comment regarding syntax highlighting, unless you have some impairement, I think everyone benefits from this. It's something that helps you recognize patterns much faster and yo…
I don't benefit from syntax highlighting and don't see how anyone does. It's pretty, but doesn't convey useful information that isn't already right there in the syntax itself.
It's syntax emphasis. When skimming it's easier to find a variable if variables are somewhat distinct in colour and so on.
Besides, things being a bit pretty is nice.
Re: Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?
#573One thing that’s missing from this discussion is the level of experience of the user and the type of projects they work on. How long you have worked in a particular language affects how much you will be looking up function definitions. Lots of other people working on the same project with loose standards means harder time assembling a mental model of the codebase. Someone with cursor asked to program in a new languag…
I tried new languages almost daily for Advent of Code this year, with just syntax highlighting (if it was easily available). Not getting little pop-up suggestions wasn't a blocker.
Some languages like haskell where there's a lot of underlying philosophy different from other languages was hard, but it wasn't hard because of things an IDE would help with.
Re: Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?
#574There are still a lot of developers out there that basically are at the hammer and nails level of programming. They use a basic editor with basic syntax colouring and when they write broken grammar, the editor just misbehaves telling them they've typoed something. Many still use rg and fd or fzf outside or within their editor and are anti IDE. I think ultimately they do waste time, particularly they see refactoring a…
> But renaming symbols throughout large projects without an LSP? Nah, been there, done that, for decades, and I'm glad that's over.
It sounds nice; although even with basic emacs: change the definition, compile, step through the compile errors macro-replacing. It's pretty fast and not really common.
Non-compiled languages suck though, but you shouldn't use those for big things
Re: Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?
#575Can you drive a car with manual transmission? If you can, then do you feel helped by automatic transmission? I don't. I feel like too often the automatic transmission makes the wrong choice. It doesn't feel like more work at all, and allows for much better control of engine braking. (You shouldn't be using your other hand to hold anything while driving anyway)
I moved to an EV from an automatic transmission, and I’m pretty much used to one pedal driving now (using regen to slow down and stop most of the time). No gears at all took awhile to get used to, but now it just seems a better way to drive. Manual transmissions get a bit stressful on steep hills, and so I don’t really miss them much accordingly.
Yeah EV is the bee's knees. No sudden surprise from some automatic transmission computer deciding to suddenly jolt you for no reason.
And as you say, "engine braking" with an EV is just "press the brake. It'll regen when possible".
In terms of driving comfort, my preference is EV, then manual, then automatic. But I would feel differently if I spent much time in bumper to bumper traffic. That's the one time manual is a bit annoying.
But those that would disagree with me are of course not wrong. To each their own.
Why do you say manual transmission is stressful on steep hills? Oh, you mean like starting from a stopped position going uphill? Yeah, it was a bit tricky to learn, but it's been (no pun intended) automatic for me for decades.
Re: Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?
#576When I tried to get into programming as a teenager, I opened a graphical IDE and was immediately overwhelmed by a barrage of menus, popping windows and tooltips. This led me to believe programming is not for me. In later attempts I used vim (back then that's what people used to recommend those starting out with perl) and felt right at home.
These days I still use vim (almost stock) for everything (right now mostly Rust). This is totally anecdotal, but I'm usually more productive than my teammates - mostly because of the initial hurdles of getting into a new codebase or parts thereof. I don't have anything to set up, I just open it up and grep my way to success.
Every now and then I try to open an IDE and force myself to work with it a little bit just to be sure I'm not missing anything. The visual overload and lack of advanced editing are just too much for me. Going back to vim is always a breath of fresh air.
I'd sooner use nano/notepad.exe than any sort of graphical IDE (though I prefer vim).
I'm not saying this is the best way, I definitely do not recommend it to those asking me how to get into programming, but it's definitely the best one for me.
Re: Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?
#577Earlier quoted context omitted.
You're erecting a pretty detailed strawman here. It's not that "raw dogging" code makes you a better developer; it's that specifically jump-to-definition and autocomplete make it too easy to create code bases that may as well be huge bags of functions and classes, and that skipping the mental work of organizing the code limits the fidelity of the mental model you can build.
Programming languages are complicated. Their standard libraries are extensive. Real world application are usually not trivial, because they often model real world processes, and the real world is messy. Anything we can do to make writing software easier and more reliable, and reduce cognitive load, is going to benefit the software developers who are involved, and will make the systems better. I'm sorry, if you can't…
We're SWEs; the temptation to min/max ourselves is quite high. And it's not a bad impulse! I'm a Vim user; I've obviously invested a lot of time in editing efficiency (e.g. I'm great at looking up docs in the terminal). Oftentimes when I need to code I can't dilly dally. I also prefer a style of dumping out an implementation as quickly as possible to prove/disprove the idea, which of course requires a lot of editing efficiency.
But the way I've gotten here is by assiduously removing things that slowed me down. Sure popping docs in your editor is faster than switching to a browser, but just remembering is even faster. If your goal is really to not "waste the company's time" then you're putting the standard library, your dependencies, your app, etc. into Anki and memorizing. Since almost nobody (some people are and bless them) is doing this, I think we should admit we're fully in the realm of personal aesthetic preferences here.
And I take a broader view of the whole thing besides. I start from the perspective that engineers are whole people with histories, futures, goals, features, interests, and opinions. For example, Go wasn't built with autocomplete and go to definition. You're more or less arguing that Rob Pike should've been forced to setup VSCode. I think that's an express ticket to pissing off and burning out your engineers; just like I'd never micromanage Pike to that degree, I'd never micromanage you to the point where I'd force you to learn Acme.
The value we bring to our companies isn't just the speed with which we crank out code. The value our companies give to us isn't just a salary and benefits. We have more nuanced and complex human needs, and sacrificing those for extreme coding efficiency may provide short-term gains, but the long-term effect is pretty grim (ponder for a moment working at a company that actually cares about efficiency to the degree they'll micromanage your editing workflow).
Re: Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?
#578Earlier quoted context omitted.
I myself coined a term "kitchenware principle" that I have applied to my codebase as well. You put forks and knives adjacent because they serve similar utility and common purpose. Same with plates, cups, weird gadgets in separate drawer. You should organize your code similarly and with as little fanfare. They are just tools, dont get clever with them. Sometimes, you get too many forks in same holder so you have to di…
so `utils` is pretty much the 'junk-drawer' of the kitchen then ;)
Certainly and nothing wrong with it. Just have to make sure no forks get lost in there. And I myself have started to prefer more intellectual "lib"
Re: Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?
#579This thread is certainly eye opening. It reminds me of a post I saw somewhere, maybe on Reddit, where someone was describing their experience working as an intern at an old-school tech shop. All of the developers there were hardcore Vim/Emacs users with 20+ years of experience. The intern was tasked with a large-scale refactoring of some modules which the senior devs estimated would take months of work to complete. A…
Work at a "tech shop," even old-school ones, most likely involves extremely varied types of work, much more than name-refactoring, for which something like IntelliJ indeed would be the best tool. Just because one use-case of one tool being better than another use-case of another, doesn't imply that users of the former are stubborn/unintelligent/worse than the others. Maybe there's a use case where the Vim user is at an advantage.
The fact that the market hasn't outright eliminated such people goes to show that things like LSPs aren't that extreme of an advantage.
Re: Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?
#580Earlier quoted context omitted.
> it never really occurs to us to use them, just like it never occurs to you to not use them. This doesn't really make sense, either. How do you not consider the right tool for the job? Do you just use whatever you learned to code and never really bothered to consider that you might be more or less productive with different tools? LSPs don't always offer a productivity increase in all contexts—they seem to be mostly…
> This doesn't really make sense, either. How do you not consider the right tool for the job? The thing people keep trying to explain is that when it comes to this stuff, there isn't a "right tool" for every job and every programmer. You like LSPs? Great, use 'em. You don't like them, and you can be just as productive without them? Great, turn 'em off. So many people yelling at each other over personal preferences. I…
One group sees the other as a person backpacking with a bespoke gadget for every little thing, wearing a 60lb rucksack while they are wearing a 20lb ultralight pack and have a multi-tool that serves 90% of their needs.
One group sees the other as a person with a reel-mower proclaiming they don’t need a tractor mower, while they can mow much less grass a day.
Both groups are right, and both are wrong. Depending on what you’re doing, it can make sense to use heavyweight tools, lightweight tools, little tooling, or lots of tooling. If you’re hired into a big codebase written over the course of ten years, skipping tools that will help you make sense off it is probably not the right choice. If you’re building a system from scratch, then those same tools might inoculate you to the dangers of having a poorly organized codebase. If you need to debug a server remotely, bring productive in vim and basic command line tools could be invaluable. But if your debugging stuff, you could have saved yourself hours by turning on a debug port and stepping through the code in a debugger.
The arguments everyone is having look to be about whether it’s worth it to learn how to use tools. The answer is yes, but everyone has their identity caught up in their pet workflows.