I'd argue that it's not benign. I think there are very real costs.
First off all, "misuse" of autocomplete can be very annoying. Some autocomplete system autocompletes when you press tab, some when you press enter. Many times I've been typing a thing, finished the line with the autocomplete window still open, pressed enter to go to the next line, and instead have auto-complete enter a bunch of stuff I don't want. These kinds of annoyances go away if you learn the system properly, so it's not a huge deal, but it's there.
More serious is the visual noise. I type while looking at the screen, and having a window pop up like that is distracting. It forces attention to itself since it's right next to the cursor (which is where I'm focused), and you have to process it. There's a reason people build elaborate "distraction free" practices, and we all know that being distracted by sudden inputs can break "programming flow". Auto-complete does this for me. It's not that I can't work with it, I just feel much more focused when not using it.
Like, imagine if auto-complete was enabled when writing just regular English. Every time you get half-way through writing a word, a window pops up suggesting that the ending of the word "parli" is probably either "parliament" or "parlimentary". That would be super-annoying, right? There's a reason Microsoft Word doesn't have autocomplete in this way, and it's how I prefer to program.
Third, I do think there's a more insidious effect of over-reliance on auto-complete. I genuinely think it leads to bad practices when designing a language, because you come to rely on it. Type names and lines become longer and you start to use more inline namespaces.
I think of C++ chrono library as an example of this. It seems like a library entirely designed to be used with autocomplete, because no sensible human without autocomplete would design a library like this:
auto start = std::chrono::high_resolution_clock::now();
// .. do stuff
auto end = std::chrono::high_resolution_clock::now();
auto elapsed = std::chrono::duration_cast<std::nanoseconds>(end - start).count();
I think (but am not sure) that's the correct std::chrono way of measuring a duration and get the results in nanoseconds. That's just an example, and you can argue with it, but I feel like auto-complete encourages this style of programming, and I don't like it. I don't like to type it, and I don't like to read it.
Again: I know I'm the weird one. Tons of programmers I've worked with and respect love auto-complete, and for good reasons. But I think there's a downside that most people don't consider, but maybe should.
I personally see your first two arguments the exact opposite way.
The visual display functions a bit like subtitles on TV: I don't really notice it's there, until it can help me. Just like subtitles help when I don't immediately understand something, autocomplete helps when typing something takes a bit longer than I'd like it to or when I'm not entirely sure what I want to write.
The "misuse" of autocomplete always continues to affect my workflow, because I can never ignore it. When it's wrong I have to explicitly opt-out from having it do the wrong thing, instead of quickly opting in to the right thing when it makes sense. It's a lot like auto-correct on phones, correcting words that weren't wrong in the first place. The fact that the popups capture arrow keys makes this effect significantly worse.
After some configuration I now have Emacs set up to handle this perfectly. Enter and movement commands always work like they normally do, never depending on the state of the autocomplete popup. Whenever it's there I can quickly make use of the autocomplete popup using Alt. It never does the wrong thing, because I would have to consciously tell it to do the wrong thing. When it's opt-in, autocomplete for regular English is actually a delight. I notice myself quickly auto-completing long words that take longer to type out.
I fully agree with your third argument. In my experience libraries and language ecosystems that fully expect autocomplete, like Java, tend to become overly verbose. The length of a name or expression affects the reading cost, but autocomplete mostly removes the equivalent writing cost. This then allows programmers to quickly give up on finding better names, or clearer ways of doing things.
You dismissed your first argument, and I agree, it's just a matter of learning the system - I mean, I don't think anyone here can genuinely argue that VIM is bad because it's hard to learn.
Regarding the autocomplete, GMail does do this. It was a bit jarring initially but now I either accept the option or continue on as if it didn't exist.
I'm not sure what your argument for the third is - that it leads to code that relies on auto-complete? Isn't that in fact an optimization? Those lines don't seem particularly egregious to me. I don't know much C++, but I could see exactly what it was doing with those lines of code by being able to read the variables. Is it verbose? Yes it is. I don't take the idea that coming to rely on a tool is a necessarily a bad thing. C# visual studio debugging is head and shoulders above Console.WriteLine() - is it necessary? No, but it's greatly sped up the development process. Same with not having to go to the command line each time I want to compile and run my application.
I understand you understand you're an outlier, and I know you're just making personal arguments, but it kind of feels a bit "old man yells at cloud" - and that's not bad, I just thought there was value in debate.
It looks like the trend is toward autocomplete suggestions for English too. On my phone keyboard, there are autocomplete suggestions to choose from when typing, and GMail now has Smart Compose [1] to do the same thing.
Re: editor trying to be helpful but getting in the way
Sublime Text often inserts "matching" quotes and parentheses. But it doesn't always do the right thing, so I usually have to go back and erase it. But then it erases the original one, too. So I have to move the cursor, add a space, and then erase it.
And when the feature does do what I wanted, it's only saving me literally 1 character --- ~0.1 seconds at my typing speed.
I really have problems with Sublime Text's autocomplete, to such an extent that I can't quite be sure whether it's a net gain or loss. If I was sure either way, it wouldn't be a problem, of course — I'm pretty sure it's easy to turn off altogether, if that's what you want.
A common example is copying some PHP source code into a new file, then entering "<?php" at the very top of the file. If I'm working quickly and do the natural thing (i.e. hit ENTER afterwards), I end up with "<?phpversion" and I either have to manually delete it, or do a cmd-z dance. Or I have to remember to press RIGHT after "<?php" instead of ENTER.
Many other similar examples (quote characters often seem to cause a problem). But, on the other hand, I know I've made use of autocomplete to help me type a long constant name which happened to be in the same file. So ... swings and roundabouts.
It isn’t doing the quote matching to save on your typing, but to keep your scanner from providing the wrong tokens to the parser of your compiler that is running all the time while you are typing.
First off all, "misuse" of autocomplete can be very annoying. Some autocomplete system autocompletes with you.
IN ORWELLS REALITY: It isn’t doing the quote matching to save on your typing, but to keep the scanner from providing the wrong tokens to the parser of a compiler that is running all the time while you are typing.
If you want the compiler to be useful while you are typing, then the designers of your tooling have to do something. You can argue that they are doing the wrong thing, you can argue that having the compiler running while you are typing isn't worth it because you don't need the feedback, but don't misidentify why they are doing it; they aren't doing it to help you save a millisecond on typing, that isn't the concern at all.
Like, imagine if auto-complete was enabled when writing just regular English. Every time you get half-way through writing a word, a window pops up suggesting that the ending of the word "parli" is probably either "parliament" or "parlimentary". That would be super-annoying, right?
iOS does this and I assume Android does also. In fact, it’s based on what you type frequently. For instance, I use some phrases so often that I get autocomplete suggestions for them as well as company specific acronyms.
I tried this once. I can do it easily with natural language but it's much harder to do with code (even code you're familiar with). I think this is because so much of writing new code is back-and-forth:
start writing loop, realize I need another variable, go back and initialize the variable, back to where I was, oh this should be brought out into a function, ah this function should is now getting quite large I need to split it, back to where I was, oh that should be an array not a map etc.
I like Visual Studio's 'jump back to where I was' (Ctrl+-) feature because it leaves a trail of bread crumbs across the many files I'm working in of what I've been doing and what's left to be done to implement feature x.
> I tried this once. I can do it easily with natural language but it's much harder to do with code (even code you're familiar with).
hm, that's interesting. I generally know pretty well the code I want to write before writing it. The question is what is the fastest way to get it from mind to buffer.
No one would design an autocomplete for written language because we remember the words we are going to use, and anyways, if we forget them, there is no hierarchical namespace to browse and navigate.
What autocomplete has enabled are deep and broad namespaces in programming languages that do support such a concept. Yes, you are definitely correct that the massive namespaces designed today are only possible because of autocomplete: libraries can cram in more functionality because developers will be able to use autocomplete to find it. But what’s the alternative? Less functionality in the libraries so they can be used with autocomplete turned off? There is some merit to that point of view, but simplification can only go so far before you are just missing things you wanted to use in some niche use case.
> No one would design an autocomplete for written language
Er... that happens all the time: various word processors, text messaging, etc. Even Google's autocomplete (which is a rare example of autocomplete being really good) is essentially this.
Ya, I should have written it differently. These aren’t the same things, really. One is about discoverability and the other is about handling input method deficiency. I remember auto completion being really great when using T9 to text on old Nokia handsets, but not because I didn’t know what words I could write.
The right word for that would be code completion or more specific brandings of intellisense, which is completely different from things like T9.
There is, but the space is vast for those. A better analogy might be a possessive, like the King’s crown, or perhaps an operation, the president’s impeachment. But we usually use language to communicate, not to design and build, so you aren’t gaining much when you already know what was done or to be done and are just communicating that. Instead, think of auto completion as a planning aide to help you remember what things have and can do.
The right word for that would be code completion or more specific brandings of intellisense, which is completely different from things like T9.
First off all, "misuse" of autocomplete can be very annoying. Some autocomplete system autocompletes when you press tab, some when you press enter. Many times I've been typing a thing, finished the line with the autocomplete window still open, pressed enter to go to the next line, and instead have auto-complete enter a bunch of stuff I don't want. These kinds of annoyances go away if you learn the system properly, so it's not a huge deal, but it's there.
More serious is the visual noise. I type while looking at the screen, and having a window pop up like that is distracting. It forces attention to itself since it's right next to the cursor (which is where I'm focused), and you have to process it. There's a reason people build elaborate "distraction free" practices, and we all know that being distracted by sudden inputs can break "programming flow". Auto-complete does this for me. It's not that I can't work with it, I just feel much more focused when not using it.
Like, imagine if auto-complete was enabled when writing just regular English. Every time you get half-way through writing a word, a window pops up suggesting that the ending of the word "parli" is probably either "parliament" or "parlimentary". That would be super-annoying, right? There's a reason Microsoft Word doesn't have autocomplete in this way, and it's how I prefer to program.
Third, I do think there's a more insidious effect of over-reliance on auto-complete. I genuinely think it leads to bad practices when designing a language, because you come to rely on it. Type names and lines become longer and you start to use more inline namespaces.
I think of C++ chrono library as an example of this. It seems like a library entirely designed to be used with autocomplete, because no sensible human without autocomplete would design a library like this:
I think (but am not sure) that's the correct std::chrono way of measuring a duration and get the results in nanoseconds. That's just an example, and you can argue with it, but I feel like auto-complete encourages this style of programming, and I don't like it. I don't like to type it, and I don't like to read it.Again: I know I'm the weird one. Tons of programmers I've worked with and respect love auto-complete, and for good reasons. But I think there's a downside that most people don't consider, but maybe should.