5 ms·
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, libr
by csomar 2y ago
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.
- not-my-account 2y agoDo you have your neovim config public?
- csomar 2y agoNot really, as I have API keys and other stuff in it unprotected. However, I used this as a base (https://github.com/ayamir/nvimdots 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.
- hirako2000 2y agoIf 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.
- csomar 2y agoWhich is why I mentioned that I am coding in Rust. They are the same docs.
- alpinisme 2y agoI 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.
- csomar 2y agoI 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.
- hamandcheese 2y agoI 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.
- powersnail 2y agoIf 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.
- bdhcuidbebe 2y ago> 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)
- deleted 2y ago[deleted]
- thwarted 2y ago> 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.
- PittleyDunkin 2y ago> 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.
- thwarted 2y agoMy 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.
- PittleyDunkin 2y agoYes, very zen. How does your pairing partner feel about this?
- oneeyedpigeon 2y ago