I am sure that it made me a better programmer as I know a lot of stuff by heart, where a lot of "auto" programmers are merely constantly picking of a list, which I think breaks their thinking flow...
Which is basically the same as not using the vim muscle memory for me..
Consider a piano player that needs to look up the right keys before every stoke.. The never get a feel for the music..
Programming is not remotely the same as playing the piano. This and the sibling "I don't make mistakes" comment just seem like excuses to me.
And why would one need an excuse for setting their development environment up the way that works best for them?
Which comment are you referring to you? IshKebab (the user you are replying to) was replying to svennek (not you).
> This and the sibling "I don't make mistakes" comment just seem like excuses to me.
At the time of IshKebab’s comment I was the only sibling comment.
> I’ve learned not to make the mistakes
I have learned not to make the specific mistakes that the linter used to tell me off for making, so it doesn't tell me off any more. That's a very different thing from "I don't make mistakes", which is what you incorrectly claimed that I said (even with quote marks around it, implying a direct quote!)
I read OP's position as: If you don't use aurocomplete you'll remember the naming variations better, and won't have to look them up all the time.
I still think aurocomplete might be faster for libraries you haven't used much before, but it doesn't sound at all unbelievable to me that the brain works as stated.
Nowadays, I just leave autocomplete on for minimal flow break no matter what language I'm using at the moment. I don't want language-specific names and structures interrupting the flow of models and ideas from my head.
I don't know how it is for others.
Also, I really try to minimize complexity and not ending up in the javascript npm dependency spaghetti..
Good code is simple and obvious....
Possibly, but I still need to read the librarys documentation carefully, where I plan my code anyways...
I have seen so many "auto coders" write 100+ lines of extra code because they missed reading the manual carefully and doing it correctly/efficiently...
If lines of code is your metric, that is great, if not, not...
I didn't say, that I don't make mistakes. It is rare that I make it a quarter of an hour before fucking up... luckily I am good at fixing it :)
But again, if you like your IDE, use it.
I have (almost) one decade of using IDE vs. two of not using an IDE and I strongly prefer the freethinking of the latter...
In the past decades I have written (and still do) like 50/50 in IDEs and plain to somewhat less plain text editors, and if there's something which is a flow breaker for me, then it's coming up with the exact name and method in such plain editor when I just know there's one which does what I need but cannot remember the exact name. Fuzzy matching it against a list doesn't break any flow for me on the other hand.
Which matches how my memory works: I cannot remember hard facts and data well (function DoSomethingVeryHardCore). However I'm good at remembering abstract things (function which does something hardcore). I am pretty sure learning many things by heart from the many very different codebases I work on would be a complete waste of time. Instead learning some abstract mental model of the codebases architecture, and how to navigate through it in text, is what makes me fast and efficient.
I could feel my "clarity" fall year for year.. I have never looked back.
I stand by my original statement, that for me, IDEs hinder my thought.
Also, I have seen other coders I really consider high-end having the same considerations (it might just be a bias, where I just notice those, who agree with me)..
Have you ever seen the "competitions" where they give a really really good photographer (or videographer) a 50$ toy and lets them compete against an amateur with a really high end setup..
Only amateurs blame their tools (above a certain minimum threshold)..
I tried 'Ctrl-x' but it decrements the integer under the cursor by 1. I tried 'f' but it starts a new motion command to search the next occurrence of the character following it to the right. Example: 'fx' will place the cursor on the next occurrence of 'x' to the right.
How can I use 'Ctrl-x f' to look up a file name?
Here is a description of it and a few other insert mode commands: https://georgebrock.github.io/talks/vim-completion/
I've bound some complete-plug-in to tab, but that's pretty much all I do in insert-mode command-wise.
I -personally- find it way more comfortable than even a minimal vim install because when I typo a command it beeps at me, whereas in vim I generally accidentally activate a command I don't understand and get broken out of flow while I figure out wtf just happened.
I don't at all judge people who're IDE wizards, I've not seen any correspondence between maximalist versus minimalist taste in tooling and competence, but this approach works way better for me.
This doesn't happen to me very often anymore but when it does I’m grateful for multiple undo, I’d be scared to use an editor without it.
> where a lot of "auto" programmers are merely constantly picking of a list, which I think breaks their thinking flow...
For me, typing when the computer can type faster than me breaks the flow. Though your auto complete is very bad if it needs you to pick things from a list - 99% of the time it's just "type a couple of first letters, <ctrl-space>, repeat for the next token."
> Consider a piano player that needs to look up the right keys before every stoke..
Most professional classical musicians play with sheet music, no ?
That is WHAT to play, not how to play... also I actually thought more of improv players, but that wasn't stated :)
I think, my fingers type...
I spend 0% brain cycles on typing (it is pure muscle memory), which why picking from a list (or checking that autocomplete choose the correct) is more brain work...
but, it's definitely not "more brain work", just like stenography does not take "more brain work" to write - when you're used to it you don't need to look at the autocomplete output either, it's just a very shorthand way to get things from your brain to your computer.
For me, checking whether auto-complete choose the correct is more work that typing the correct thing, as my fingers type on their own - almost without supervision...
I have written code for 30ish years (professionally for 25 years) and I have honed (and still hone) my environment for maximally "transparency" so that my though is not hampered by tools..
If that is not true for you, then use your IDE and be happy about it... Nothing wrong with that, at all...
EDIT: also fun, that you highligt stenography that is the definition of learning-curve/musclememory ... :)
but, that's the thing, I don't even remember the last time my autocomplete didn't complete the right thing. So yes, I entirely trust the algorithm, it has already saved me so muchtime.
I have never liked autocomplete. If I know the type or method I’m looking for (which is most of the time) then typing its name is not a hardship, and takes really no more time than finding it in a list.
If I don’t know the type/method, most of the time I have the documentation up in another window or monitor, and I’m going to want to read that in depth anyway, since I’m not familiar with the type/method, so autocomplete wouldn’t save me any meaningful time.
I am experienced in both Java and C++ and while I can read/write/refactor code in C++ just fine with Vim, doing so in Java without a sophisticated IDE is a painful experience.
I don't really like realtime linting, autoformatting, or error highlighting either. I find it highly distracting, and usually it's complaining about something I was already going to fix anyways. I'd rather have such things done only when I intentionally trigger them. I'd say please stop whining about syntax errors and test failures in code that I haven't finished writing yet.
I've tried some Git plugins, but never got into those either. I still prefer the gitsh cli application for most of my Git work.