With auto complete I rarely type more that a character or two of any single thing. I doubt it takes me much longer to compose a traditional program compared to array language syntax with modern tooling.
If you use it as a programming partner it will simply autofill whatever you're writing line-by-line. You're not forced to use code completion at a whole-function level and it's not even the suggested use-case.
I guess you can code without auto-complete but that would mean having to check the documentation at every step instead of having it auto-completed on the go. Depends what people prefer, for me it's a step back.
I don't want to argue on your other points but imo the part of auto-complete that saves typing time is the least important thing in a IDE. The really useful part of auto-completion is actually exploring unfamiliar APIs.
It all depends on your average typing / coding speed. Autocompletion doesn't offer a lot to someone who knows the language framework really well and type 90+ wpm. You may even find it's annoying more than helpful most of the time.
I'm not that fast and to be honest I really don't miss code completion at all.
Code completion (not auto complete) was always meant for discovery and never to help save on typing, at least in textual environments. The idea of immediately showing you what some symbol can do without using the mouse is very powerful.
The issue with autocomplete is that it makes writing a lot of code really easy but offers no help when reading the code. Syntax/semantic highlighting may help a little but the issue is still there.
Given that more time is spent reading than writing code, autocomplete is only a partial solution to this problem.
So a computer can type a sample from a coursebook into the editor for you, after much prompting, fiddling, and tabbing from you.
Well, I guess it's marginally better than typing in printed listings from a computer magazine, like we did in the 80's.
Seriously, folks, having Copilot regurgitate code into the IDE for you which you A) could have found yourself and, B) don't understand anyway is not increasing anyone's productivity. It's turning their minds to Jell-O. The more we rely on auto complete for programming, the less complete is the programmer's mind.
> Auto completion? Re-factoring(grep and replace doesn't cut it)? Code generation?
Auto-completion is an editor feature, and support for auto-completion in text-mode editors is not a problem, though I don't use it as I hate auto-complete with a vengeance. If you need to type enough for auto-complete to matter, your language and/or your identifier names are messed up.
Re-factoring and code generation are features I expect of the editor and/or external command line based generators respectively, and there's no reason for a heavy IDE.
I can understand people grab onto IDE's if forced to deal with ridiculously verbose languages like Java or C#, possibly. Yet another reason to stay away from these languages.
Usually you can just start typing and then use some kind of automatic completion, much more efficient than hunting down multiple variables in code and copying them.
Screens are huge now. You can fit long names. Auto complete makes typing long names easy. Let your code read like prose. Save the brain for solving the business problems not for understanding the code.
> Auto-completion is no doubt a large part of what's enabled your AbstractBeanFactoryProviderImpl to get those 33 methods in the first place. Which is a big part of my point, autocompletion shapes the way you think about code, shapes how you write code.
Sure, but that doesn't necessarily make it better or worse. People have written horrible code without auto completion, just like they have written horrible code with auto completion. I'm not convinced that you just magically get better at thinking by making your life harder and typing more for no real reason.
> There are also a lot of examples of functions that, by name alone, do not do what they seem to do. That shouldn't be, you might say. But even in the face of that objection, they do exist. It would be very easy to jump to the conclusion that for example "Boolean Boolean.getBoolean(String)" parsed the string and returned its boolean equivalent.
And not having auto complete doesn't help with that at all. Auto complete MIGHT also include commentary for the function and explain what it does (if that commentary exists in the first place) and at least help with the issue.
I'm totally of the opposite mindset. I think auto-complete is a terrible way to introduce someone to a new language.
Yes, you may see results quicker, but I've found all that happens is you become reliant upon auto-complete to do the thinking for you. All too often I have seen people use auto-complete as a tool to help them just mindlessly code away rather then taking the time to actually figure out what it is they are trying to achieve. Forcing yourself to actually look at the API and type out a function name cements a concept so much more then autocomplete.
reply