Hacker News Reader

Comment by csomar | Hacker News Reader

I use Rust, so explicit imports are required. However, I fail to understand this point

> You’ll learn where all the reference docs live for your language, libraries, and frameworks, and along the way you’ll learn more by actually reading the docs.

With neovim/LSP, I have a key binding (Kg) that opens a small window within the editor with the rustdocs. Not only this is faster than going to the browser, typing the type name, opening the docs, looking up the method but also it ensures that I am looking at the docs of the correct version that my code base is using.

I don't really understand the aversion to using these tools. They are "auto-complete" and not generative complete. This means you need to know what you are going to type for them to help you.

View on HN

> I don't really understand the aversion to using these tools

No one is yucking your yum, it's not an aversion, it's that we don't need them, it never really occurs to us to use them, just like it never occurs to you to not use them. You make it sound like people who don't use them are fumbling and tripping over themselves and aren't actually writing any software.

> 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 useless for dynamic languages like ruby and lisp and javascript—but I have a hard time imagining a programmer that couldn't benefit from them in the right context.

And they're just a straight-up improvement from iterative compilation and ctags, the latter of which never really worked very well in the first place.

My great-grandmother never used a mixer when making cakes or bread, long after mixers were available, and she was able to pump out treats and full meals without batting an eye, the best anyone ever had.

I don't have a problem with my "productivity", whatever that means. I'm not trying to write code faster, my own experience is that writing code faster leads to shitter code. I'm not hindered by my tools, and most of my programming time is spent thinking and understanding, and none of these tools have afforded me better thinking or understanding, and often times they get in the way of my thinking.

Yes, very zen. How does your pairing partner feel about this?

> I'm not trying to write code faster, my own experience is that writing code faster leads to shitter code.

I'm wondering who these programmers are who are sitting down for eight hours a day, pumping out perfect code at 200wpm without any breaks. I suspect they might not exist.

I was more suspicious that they refuse to engage in the concept of productivity at all. Why bother using computers in the first place, then? There are more beautiful things in the world to contemplate than code.

Your typing speed is not the limiting factor in productivity. You have to think carefully, plan a solution, then put out code without errors. Not using LSPs helps you accurately model the code in your head ahead of time and increases your accuracy. It's slower at first but much faster in the end. Because your typing speed was never the limiting factor in your productivity.

I didn't setup the tool to write code "faster". I setup the tool mostly to reduce RSI because I wouldn't need to use the mouse as browsing docs with vim only uses the keyboard. I do agree that you can't write code "faster"; whatever that means but that was never my purpose.

You should give these tools a try. From my perspective it's like someone sitting on a small wooden chair and you are proposing an Aeron. Yes, they are both chairs and you'll be sitting and perform the same task but boy the ergonomic chair will save you from some real back-pain.

> wouldn't need to use the mouse as browsing docs with vim only uses the keyboard

I recommend adding a Vim keybindings extension to your browser.

> I setup the tool mostly to reduce RSI because I wouldn't need to use the mouse as browsing docs with vim only uses the keyboard.

Meanwhile some of us already had setups broader than that in scope: I use vim, a tiled window manager with vim-like keybindings, and Tridactyl to control Firefox with vim-like keybindings. Can do just about everything without touching the mouse, including browsing HN and other sites.

I also cook and bake and I am using a mixer. And other tools too, like a food processor, a thermometer, scales, a dishwasher. Could I make do without them? Sure, as I have in the past. I understand my tools and how to apply them; I chop small amounts of ingredients and I don't wash my knives in a dishwasher. But I recognize the value of the tools. With them, my results are consistent and higher quality.

Plus, I have more time and energy for writing code later. Or other activities.

I admire consummate professionals who can immerse themselves in the craft. I can't do it. I still put out great work - definitely not the best ever - and the tools lessen my mental and physical burden. I have more energy that I can spend elsewhere.

We replaced the punchcards and terminals and line editors with different tools because the trade-offs were worth it. Maybe we can keep adapt new tooling in a similar matter when it makes sense.

i avoid using autocomplete because it forces me to think about every single thing i’m doing.

every line of code is a liability. every line of code needs to be thought about. every line of code is precious.

spamming autocomplete means i’m not thinking about what i’m doing, even the simple stuff like writing a for loop statement.

I don't use autocomplete, either. Most of what an LSP gives you is more data to scan semantics faster.

> every line of code is a liability. every line of code needs to be thought about. every line of code is precious.

I personally think this is ridiculous. It's code. It's just formal instructions. You process them and move on. It's not describing the face of god. If you need to think so much write less clever code.

Great, another pragmatic programmer producing sphagetti

Code is read more often than written. It's not make the computer do something and done.

The right kind of clever results in "oh, it can be that simple?", not "what the hell is that line noise?"

it’s nice to be able to fall asleep and someone else does the reply you wanted to do. you saved me a job. =p

That doesn't mean you stare at it in stupefied awe. If you can't remember what you're working on you close your computer and walk away.

i never said i stared at code in a stupefied awe. that’s your stuff, not me.

the point i was trying to convey with the phrases was my ideal attitude when writing code.

this code matters. lets think about it, get it done right and not throw it over the fence for the poor schmuck who comes along in two years time after we’ve all left.

i’ve been that schmuck. it was horrible. i don’t want to put other people through that. ever. (this is now my stuff, but hopefully explains some of the attitude).

our attitudes, intentions and motivations count when it comes to code quality. look after your code and it will look after you.

that’s what i feel. you feel different? that’s fine.

What does this have to do with a language server? It is not a tool that blinds you, nor one that puts a gun to your head and forces you to ship prematurely.

I'm just very confused how the conversation took a turn away from pragmatism and towards the aesthetic.

> > every line of code is a liability. every line of code needs to be thought about. every line of code is precious.

> I personally think this is ridiculous. It's code. It's just formal instructions. You process them and move on. It's not describing the face of god. If you need to think so much write less clever code.

you called my attitudes to writing code ridiculous. i thought i’d provide you some information on why i hold that attitude. maybe it might help you understand. maybe you may consider your own attitudes as a result.

it seems to me that you are not ready yet.

> 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. It's not enough to have the tool and use it, you need everyone else to use it too? Why? To validate your own use of the tool? If you really truly believe it gives you an edge, great. I don't think it gives me one, and anyway, not everyone fights with the blade.

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.

If you browse through the doc, you will find yourself reading the doc.

If your code editor looks up the doc, you find yourself reading what the code editor shows you.

Wikipedia, (real) historians have some aversion to using it. No argument, it is convenient.

Which is why I mentioned that I am coding in Rust. They are the same docs.

I think the point they are making is that you only read what is shown you instead of seeing the full docs and being encouraged to follow rabbit holes and browse nearby info. Speaking for myself, this has been one of the largest boosters in my own career: visits to a docs page that led to me basically reading the whole docs.

I am not sure if we are speaking about the same thing. LSP can give you type hints. What I am doing is that I am opening a "window" in my editor that has the full docs. You can browse through it freely. The issue with "non-Rust" languages is that the docs will be on a website. On most Rust projects (90%+), the libraries will use the Docs system which makes the docs fully available on LSP.

I believe the distinction is that if you have to manually browse the docs and navigate to the method of interest, you might see something else interesting along the way.

Whereas if your editor takes you directly to the method in question, you miss that opportunity.

If I want to read through the doc, I'll just do that, and I frequently do it with all dependencies that I'm directly interacting with. As fun and informative as it is, personally I don't want to do this exercise every time I need a peek at the documentation of a class or function, in the same way I don't take a detour into the mountain every time I get out of my house, as much as I enjoy hiking.

> The issue with "non-Rust" languages is that the docs will be on a website.

We have tooling for offline docs of course. See dash (macOS) or zeal (win/linux)

> you only read what is shown you instead of seeing the full docs and being encouraged to follow rabbit holes and browse nearby info.

I can use a convenient shortcut to go as deep as I want in the codebase, including libraries. Meanwhile crowd with clinical case of tool aversion will spend time fuzzy-searching and manually sifting through text.

Who's encouraged to explore more?

Do you have your neovim config public?

Not really, as I have API keys and other stuff in it unprotected. However, I used this as a base (https://github.com/ayamir/nvimdots) and heavily modified it. There is a user directory (lookup the user_template) where you can config everything out of the base.

Reply on news.ycombinator.com