You know, I realize I'm the weird one here, but: when writing code, I almost always turn off autocomplete. Sometimes you basically have to have it on (when the language is demands it) but I usually turn it off. It's too much visual noise, too distracting. It's a thing that pops up that demands your attention. If I want to type
if (myVector->empty()) {
fillVector(myVector);
}
autocomplete will pop up a window like 4 times while writing. For no real reason: i can type "empty()" on the keyboard faster than I can look at a screen and choose "empty()" from a list, and having having the list pop up is distracting.
In fact, I strongly disagree with this:
> If I were writing a sophisticated user interface today—say, a programming language or a complex application—autocompletion is one of the primary constraints I would design it around. It’s that important.
Ugh, no, I don't like this at all. This is what leads to nightmarish Java type names ("AbstractSingletonProxyFactoryBean") that makes this language practically demand auto-complete. A programming language should be easily typeable on a keyboard without having to resort to auto-complete for everything.
I used to think this way, too, so I don’t think you’re weird. At my old workplace, everyone else was a Java IDE wizard, and I was used to good old-fashioned text editors. Aren’t you distracted by that widget appearing while you’re typing, I thought? Is it really faster for you to hit the Down arrow three times instead of just typing ‘empty’? Do people not learn the libraries they’re using anymore‽
But over time, something changed, and I’m now a big fan of autocomplete interfaces. There was something wrong with my initial assumptions, and I think that’s the same assumption you make when you say this:
> i can type “empty()” on the keyboard faster than I can look at a screen and choose “empty()” from a list
You’re right, I can type ‘empty()’ faster than selecting it from a list. I have the muscle memory already there, and I don’t need to stop and look and think about which method I’m autocompleting.
The reason I still use autocomplete is not that I need my IDE to tell me that there’s an ‘empty’ method there as if that’s something I don’t already know, but to tell me that my assumption that ‘myVector’ has an ‘empty’ method is correct!
I occasionally write code like this:
auto myVector = someFunction();
if (myVector->empty()) {
fillVector(myVector);
}
Only to find that ‘myVector’ is not actually a vector, but an optional<vector> or another type entirely that requires me to do something else to get the vector I want. At this point, if I start typing ‘empty’ and the autocomplete widget does not appear, I immediately know that I’m not dealing with the type I thought I was.
Once I started programming this way, having the window appear was not ever a distraction, because I expected it to appear. In fact, the only distraction was when it stopped appearing, when I’ve made a mistake!
> Ugh, no, I don't like this at all. This is what leads to nightmarish Java type names ("AbstractSingletonProxyFactoryBean") that makes this language practically demand auto-complete.
You have it the wrong way around. Naming like that comes from the structure of the application, which just happens to benefit the ability for autocomplete tools to understand it.
If you've ever worked on enterprise software, with hundreds of classes across a half a dozen domains, you'll know the structure comes from a need for organisation and discoverability, and without that organisation you would have a harder time finding the parts of the application you need to be aware of. Autocomplete is just a convenient way to search the codebase for what you want. But that structure is the real hero.
I'm a bit confused - isn't autocomplete utterly benign if you don't use it? Using Visual Studio I've never had to autocomplete unless I wanted to, so I've lost no time by having it on if I just want to trudge through, but there's plenty of times I can auto-complete away whole expressions by typing a letter or two and then hitting tab.
Regarding nightmarish Java type names I'd rather the name for things be the fully written out description (like "httpClientFactory") than something that's easier to type - at a glance I know what it is and does, and autocomplete is smart enough that I can type "h" and tab and it has the variable there already. And if I don't know what it does, all that takes is a "h", a tab, and a ".", and now I have access to all its functions with descriptions, saving me a context switch and jump to the documentation.
What's often missing from these discussions is the impact on human memory.
Back when I started programming, I never used syntax highlighting. It just wasn't a thing for a large part of my early years. Text mode VisualBasic and QuickBasic didn't have it. Nor did GW-BASIC, QuickC, Pascal, I could go on...
I was at the point where I could write C code and have it compile the first time. No syntax errors, no compiler errors, full -Wall and -pedantic.
After using an IDE for awhile, I noticed my ability to get things right diminished. I gave up knowing things for relying on technology.
One area I notice this the most is spelling. I used to be able to spell. Now I critically depend on browser or editor highlighting of errors, or throwing a word into Google to see what Google tells me. And it's not just new or complex words. It's words that I used to know how to spell. If all I had were pen and paper, I would be helpless.
Some will say technology frees you to memorize other more important things. But the downside is you give up agency. And very well may just become that much more of a replaceable cog in the machine.
Autocomplete doesn’t have to be so intrusive, it doesn’t have to pop up a window over your cursor, it doesn’t have to grab CPU time making your keystrokes skip. These are really interface issues that can be fixed: you can shove the suggestions off to the periphery of the buffer, for example.
Autocomplete is and was never about saving on typing. It is an aide to help you browse and navigate large namespaces, it doesn’t enable long names, it enables deep and vast libraries. The complaint then isn’t about some straw man class name, but about the 200+ methods that can be called on that class.
I am in the same boat, but was recently told I program very differently than most people. I write a bunch of stuff that does not attempt to be syntactically correct (everything from while(???){ } since I don't know what the exit condition is yet, to straight up interlacing "a --> something --> b" or random ascii drawing of trees, in the middle). To me code is very similar to writing an essay, especially at the beginning, I'll have random lines all over the place as I develop the idea, and only reign it in to something that will actually run much later. For this reason, I also am totally OK without syntax highlighting often. My editor of choice has a bug where it often won't syntax highlight on the creation of a new file and you have to manually reselect the language. I actually like this and treat it like a feature: new files start in "brainstorm mode" and only "earn" syntax highlighting once they are sufficiently mature, at which point the environment becomes more constrained. This kind of accidentally mirrors the behavior of CodeWarrior which I used to love for C++: before the age of running a daemon in a parallel process to syntax highlight, CodeWarrior would only "know" the classes and methods you defined on the last successful compile. This was simple and fairly bullet-proof: no need to clear any weird caches or anything, no crashing background thread trying to highlight incorrect code, new classes were unrecognized until you hit compile.
That being said, even if I programmed with the intent of continuing to be syntactically correct during the entire process (which I do when I am editing an existing file usually), I still cannot stand autocomplete, or really anything beyond simple syntax highlighting, because I feel like everything about today's computing experience is yelling at me. Notifications constantly popping up, linters yelling about stuff I don't care about yet, and autocomplete acting like clippy telling me every possible method that starts with an S. I find it severely distracting. I wouldn't want Microsoft Word to tell me every verb that starts with "s" just because it knows that in this position of the sentence I must be typing a verb and I just hit an "s".
I agree, and it's part of the heavyweight interfaces of a lot of these modern tools. For example, search is my primary cursor motion command in Emacs, because it's incredibly lightweight and typically faster than any other cursor move command. Whereas invoking search in many programs from word to IntelliJ will move the cursor and focus away from where you're working to some widget elsewhere, and often requires a confirmation to perform.
Incremental search is finally appearing in some browsers, bringing them into the 70s. But just as software itself has seemingly gotten slower as the machines have sped up, I feel like the interfaces have gotten significantly more cumbersome.
Not all auto completions are equal, I suspect you've only dealt with bad ones.
It's very tricky to get right and requires a lot of attention to detail in timings, human attention span, UX, and even psychology.
IDEA's auto completion is mostly good, in my experience, not sure if you've tried it.
> i can type "empty()" on the keyboard faster than I can look at a screen and choose "empty()" from a list,
Sure, but that's a five letter word with no camel case nor special symbols. Your observation stops applying very quickly as the code base grows.
Not mentioning that having to type all these letters and symbols (especially if you need to use the shift key) is
pretty bad from a carpal tunnel standpoint.
I agree, personally, but I am sure it is a minority perspective. I worry it might just be my unwillingness to change habits and workflow. If I am writing down functionality I usually want to complete my thought first, sometimes even in meta-code, then go back and make it proper. Like you say, autocomplete interrupts with several micro-decisions per line.
But I grew up coding in Notepad, so most editors feel like another part of the complexity stack I have to manage. Other devs seem to code with autocomplete almost like they are coding with a visual programming language. They use the mouse a lot more or keyboard combos if they are really efficient, but they anticipate autocomplete results and select variable names quickly, partly with a mental inventory of variable name options.
I think there are clear strengths to both methods. Pro-autocomplete devs seem to naturally follow the single responsibility principle (SRP) while I find that level of scaffolding obscuring at times.
Most auto complete that I've seen implemented in the last decade has timing attached to it. So if you are typing empty(), it's not just going to pop up. Rather, it waits for a pause, an indication that you aren't sure.
I also don't know of a single language that requires auto-complete for everything. I do know languages that make more use of it, but I also don't now of a single language that benefits from not having some form of autocomplete. Even your myVector example could benefit from autocomplete (either having a better name them "myString" or "myInt" or me just typing 3 keys instead of 8 for completing myVector.
Do bad interfaces exist? Sure, I don't know of a single UI element that can't be done poorly or messed up.
>This is what leads to nightmarish Java type names ("AbstractSingletonProxyFactoryBean") that makes this language practically demand auto-complete.
I suppose this is really just a matter of opinion, but it seems strange to argue that autocomplete is bad because it can be so useful that you'll definitely want to use it. Sure, it's a separate argument whether "Factory" and "Bean" are useful, but long, verbose, meaningful names are good in my opinion. A random example taken from the React source code: `attemptHydrationAtCurrentPriority`.
Somewhat less serious suggestion, not aimed at OP, but this whole thread:
How about everyone with less than two years experience with both IDEs and editors stand back so we grown ups can sort this out ;-)
On a more serious note and as someone who has been on both sides of the fence:
How about we accept that people are different? Some people like Mac, some like Linux and some - gasp - enjoy their Windows desktop.
That said, and as someone who has extensive experience from both sides, I think that if people put the same effort into learning and configuring their IDE as they put in learning and configuring vim then that might very increase productivity a lot more than last ten years worship of vim.
(And: do learn a bit of vim. It comes in really handy sometimes, just don't fall for the idea that some people sell that you cannot become a good developer without using it all the time.)
But they're customisable, if you can be bothered. I have set up a few as is, and some defaults are really handy too!
For example, `err.nn` expands to
```
if err != nil {
}
```
And that's a default for GoLand. I have set up a few custom ones that are pretty handy as well, which frees up time from typing, to actually thinking through and solving problems, as well as making any necessary verbosity easier to deal with.
While most variable names are kept short, I do go for 2-3 word variables when necessary, and have some pretty long winded function names that, IMO, improve readability by a mile, like `GetNonEmptySliceElements()`.
Perhaps you would benefit from a customizable latency on autocomplete, similar to what I've implemented when building autocomplete form fields. You don't want stuff popping up with every key press or even as someone is still typing and presumably understands what they want to type next.
If you could customize the lag after ceasing to type a key and match it to your normal typing cadence I imagine your experience and utility from IDE autocomplete would be much greater.
Auto-complete is at least very helpful in two regards:
- "Don't make me think". I don't want to wast my brain bandwidth on remembering the details of tens of thousands of the methods/properties/functions, but instead on the logics/architecture/communication of the app I'm building.
- Method/property discover-ability, especially for new classes/interfaces/libraries.
I treat it like eye candy: Just some fun, animated blandishment that makes me feel all 1337 while banging out code.
What would be nice is if the auto-complete window could be detached from the cursor and float in a corner of the editor, so I can look at it for those times when I have a brain fart and can't remember which parameter comes first in a function.
I wish more engineers cared about auto complete. A lot of software people I know say "just use vim" or "just remember things" and I feel these view points really stifle progress.
Just recently I've been trying to use Bazel for for a personal project. When you use gRPC you don't get any auto completions on generated code. I haven't been able to locate anyone who cares about this because they use some text editor configuration that doesn't have autocompletion so this is basically never going to get fixed or have traction.
If more people prioritized type hinting and IDE friendliness I feel a lot of interesting tools would take off
I could not agree more to this article. Not only am I a happy IPython and zsh user, but also like searchable menus (also refered to as "OSD search" or similar in non-Mac OS X contexts).
My feeling is that we experience a revival of keyboard-based searchable/explorable GUIs due to two reasons:
(1.) Many people use notebooks where both hands rest on the keyboard (in contrast to an external mouse where one hand permanently rests).
(2.) Desktop searches, or virtually any kind of search with a fast index took over (clearly pioneered by Apples Spotlight). That's the Google spirit of searching for things instead of clicking menus.
This is probably one of the changes where in the retrospective we can say "the 2010s" brought us. :-)
Thanks to you (and the author) for being happy users of IPython; but if you don't have complaints you are not using it enough :-) We do our best to provide good completion; but most of the work is thanks to Jedi (Dave Halter) for the completion and prompt_toolkit (Jonathan Slenders) for the UI , at least in terminal.
There is a lot of improvement that could be done to completion (time and funding missing), and we are always looking for Feedback and Pull Requests.
Side Note while I agree about the statement about Julia and bar(foo) vs foo.bar(); nothing prevent the completer to add text not at the cursor position. Having foo)<tab> suggesting to prepend `bar(` is a possibility.
Helm makes Emacs so much more discoverable . It saves me an enormous amount of time by giving me discovery of feature and for the most part approaching DWIM.
Other people have shared improvements to Bash's default autocomplete behaviour; here's mine, specifically addressing the criticisms that you have to hit tab twice and the pollution of terminal history:
# Complete unambiguously on first tab, then show completions
set show-all-if-unmodified on
(These settings go into your ~/.inputrc file.)
This means that if I hit tab for the first time, Bash will autocomplete as far as the completion isn't ambiguous; single keypress, no history pollution.
If I then hit tab again, I get a list of the possible completions.
The other single biggest improvement over default behaviour for me is this:
# Replace common prefix with ellipsis for completion
set completion-prefix-display-length 2
This will make the list of completions omit the part they all have in common.
The combined behaviour is then like this: for a directory with a few files,
$ ls
file1 file2 file3
I can start typing:
$ cat f
Now, hitting tab (just once) gets me the unambiguous part:
$ cat file
Hitting it again shows me the possible completions with the common part replaced by an ellipsis:
> Instead, for most people the killer feature of zsh is that it doesn’t re-output the prompt when you autocomplete
Actually, this, coupled with the "complete on first tab hit" is the reason I stayed away from zsh. I tried it a few times, simply because so many people are raving about how much better it is than bash, but never really switched and the autocomplete is one of the major reasons.
1. I like to see autocomplete as a history. I hit tab (twice, but I will get to that in a second) and see what my options are. I type another letter or a few and hit tab again. If I made a mistake, I can catch it by comparing the previous set of choices to the new one. With zsh, if I made a typo, all I get is an empty list and a sense of confusion.
2. Every once in a while (more often than I a willing to admit), I will hit tab for completion when I don't really mean to. Like I will type something like ls -l /usr/local/bin/<TAB>. Bash will beep at me to ask if I am really sure. Zsh will freeze and compile a list of hundreds of completions. Not much else to say about that.
You should probably try TabNine ('autocompletion with deep learning'). It is trained on a compendium of pre-existing code, and suggests really sophisticated completions. Sometimes it freaks me out how it suggests solutions, almost like having somebody code for me.
I wonder if there is a measurable difference between software written in a very basic text editor vs an IDE. Differences like naming conventions, name length, number of files etc. I've always thought that an IDE, while wildly useful in some scenarios, pushes/allows for unnecessarily complex design choices.
Or maybe I'm just trying to justify why I use vim...
I see no mention of emacs' dynamic completion, which I've been an addict of for several decades now. Rather than autocompletion based on some defined domain of possibilities, dynamic completion backward searches through the buffer to find completions. Keep hitting the key (I use Ctrl-/) and it will eventually search every buffer you currently have loaded.
I'm sure one could set up some automatic completions-generating target in a build system that could be fed into an IDE. Well, I'd certainly hope so. But emacs' dynamic completion works so well for me, with no work to get the full benefit no matter what I'm writing - code, a letter, financial docs, anything at all where I just want to hit Ctrl-/ to finish off that slightly-longer than usual term that I just used a few lines earlier.
The one genuinely great aspect of Ubuntu's defunct Unity environment was the "Heads Up Display" (HUD) that made searching and autocompleting through the File/Edit/etc. menus in every (supported) program as easy as hitting a hotkey and typing. I am a much bigger fan of Gnome 3 than Unity, but I think this should be resurrected as an option in every OS/DE.
Anecdotally, I hide the header in Google Docs/Sheets most of the time to save space, and have come to rely on the Menu Search field in the upper left (Alt+/, which works regardless of whether the header is shown) for things like renaming the doc, accessing conditional formatting, etc. Basically the few commands I use regularly which don't have a corresponding hotkey.
> Here’s why the high-bandwidth visual interface is important: The common thread in between the autocompletion in zsh, IPython, Xcode and OS X help is that it makes it easy to find hidden things.
The best I’ve seen in this regard of discovering hidden things is the Visual Studio C# auto suggestions which refractors your code to use modern language features. It’s quite magical, sometimes doing non-trivial refactors.
I find it a great way to get exposed to the ongoing evolution of C# without actively polling the language spec.
JetBrains pioneered that with IntelliJ for Java (and then for .NET with Resharper also) - it's great to see it spreading to other languages like Go and Rust too via the IntelliJ support!
Fish has one of the best auto completion out of the box, I love all you get for free with zero configuration. I used zsh before, which is great, but require so much configuration.
For a better autocomplete experience in Bash (and other programs that use the readline library) I can recommend that you put some of the following in ~/.inputrc:
set editing-mode vi # if you're a fan of VI-style editors
set visible-stats on
set colored-stats on
set show-all-if-ambiguous on
set completion-ignore-case on
set colored-completion-prefix on
set completion-prefix-display-length 1
set menu-complete-display-prefix on
tab: menu-complete
"\e\t": menu-complete-backward
"\e[Z": menu-complete-backward
> And the fact that Apple’s methods were designed for autocomplete means that the language is practically unusable in environments without it, which in practice means substantial lock-in to Apple’s proprietary dev tools since no one else invests as much.
This may be true as an effect. But these features in ObjC language (named arguments) and idioms (using them a lot, with verbose symbol names) both date from NextSTEP days, when the developer tool market was entirely different, and I doubt these language features were chosen with any thought whatsoever to this goal.
The author may not be implying otherwise, but some readers may take it that way.
From what I remember of the era, I think the motivations were more about clarity, and maybe some desire to "make code closer to human language." Why make class or method or argument or variable names cryptic abbreviations, when you can just spell them out? Won't this make the code much more readable and comprehensible, and as they knew then as well as now, code will be read many more times than it will be written.
Ruby idioms still lean in the direction of verbosity in symbol naming; perhaps both ruby and ObjC got it from smalltalk, a heavy influence to both. Which is interesting, because smalltalk also famously traditionally locks you into a particular difficult-to-write-an-alternative development environment; but at the time and place the choices were made that led to that, it also surely was not a "commercial" decision.
I switched from bash to fish mainly for its incredible autocomplete features. It's not 100% bash compatible like zsh, but doesn't need much configuration and has very good defaults.
Autocomplete is the main reason why I preferred Microsoft Visual Studio over other environments when I was in school; and then why I gravitated towards Microsoft tools as a professional.
It's not just memorizing: When working with a new or unfamiliar API, it's very easy to guess and navigate this way.
To be quite honest, when I work in environments without autocomplete, I feel like I'm learning slower then when I learn in Microsoft Visual Studio.
> I have 90 files open in emacs right now and I can find any particular one in five keystrokes. Imagine having 90 tabs open in Chrome—you could never find anything!
The Quick Tabs extension gives you autocomplete for Chrome tab titles:
Just type Ctrl+Q and you get a popup with IntelliJ-style autocomplete.
Another trick for Chrome tabs (unrelated to autocomplete) is to open a new window instead of a new tab when starting a new task. If I'm searching for information about a particular programming topic, I use Ctrl+N and do the search in a new window, then Ctrl+click or middle button click to open interesting search search results in new tabs in that window. Then when I'm done I can close that whole batch of tabs at once.
This may seem like an obvious thing to do, but I have seen people who never open a second Chrome window but just have dozens of unrelated tabs in the same window.
> If I were writing a sophisticated user interface today—say, a programming language or a complex application—autocompletion is one of the primary constraints I would design it around.
[+] [-] OskarS|6 years ago|reply
In fact, I strongly disagree with this:
> If I were writing a sophisticated user interface today—say, a programming language or a complex application—autocompletion is one of the primary constraints I would design it around. It’s that important.
Ugh, no, I don't like this at all. This is what leads to nightmarish Java type names ("AbstractSingletonProxyFactoryBean") that makes this language practically demand auto-complete. A programming language should be easily typeable on a keyboard without having to resort to auto-complete for everything.
[+] [-] cytzol|6 years ago|reply
But over time, something changed, and I’m now a big fan of autocomplete interfaces. There was something wrong with my initial assumptions, and I think that’s the same assumption you make when you say this:
> i can type “empty()” on the keyboard faster than I can look at a screen and choose “empty()” from a list
You’re right, I can type ‘empty()’ faster than selecting it from a list. I have the muscle memory already there, and I don’t need to stop and look and think about which method I’m autocompleting.
The reason I still use autocomplete is not that I need my IDE to tell me that there’s an ‘empty’ method there as if that’s something I don’t already know, but to tell me that my assumption that ‘myVector’ has an ‘empty’ method is correct!
I occasionally write code like this:
Only to find that ‘myVector’ is not actually a vector, but an optional<vector> or another type entirely that requires me to do something else to get the vector I want. At this point, if I start typing ‘empty’ and the autocomplete widget does not appear, I immediately know that I’m not dealing with the type I thought I was.Once I started programming this way, having the window appear was not ever a distraction, because I expected it to appear. In fact, the only distraction was when it stopped appearing, when I’ve made a mistake!
[+] [-] ehnto|6 years ago|reply
You have it the wrong way around. Naming like that comes from the structure of the application, which just happens to benefit the ability for autocomplete tools to understand it.
If you've ever worked on enterprise software, with hundreds of classes across a half a dozen domains, you'll know the structure comes from a need for organisation and discoverability, and without that organisation you would have a harder time finding the parts of the application you need to be aware of. Autocomplete is just a convenient way to search the codebase for what you want. But that structure is the real hero.
[+] [-] SketchySeaBeast|6 years ago|reply
Regarding nightmarish Java type names I'd rather the name for things be the fully written out description (like "httpClientFactory") than something that's easier to type - at a glance I know what it is and does, and autocomplete is smart enough that I can type "h" and tab and it has the variable there already. And if I don't know what it does, all that takes is a "h", a tab, and a ".", and now I have access to all its functions with descriptions, saving me a context switch and jump to the documentation.
[+] [-] deckard1|6 years ago|reply
Back when I started programming, I never used syntax highlighting. It just wasn't a thing for a large part of my early years. Text mode VisualBasic and QuickBasic didn't have it. Nor did GW-BASIC, QuickC, Pascal, I could go on...
I was at the point where I could write C code and have it compile the first time. No syntax errors, no compiler errors, full -Wall and -pedantic.
After using an IDE for awhile, I noticed my ability to get things right diminished. I gave up knowing things for relying on technology.
One area I notice this the most is spelling. I used to be able to spell. Now I critically depend on browser or editor highlighting of errors, or throwing a word into Google to see what Google tells me. And it's not just new or complex words. It's words that I used to know how to spell. If all I had were pen and paper, I would be helpless.
Some will say technology frees you to memorize other more important things. But the downside is you give up agency. And very well may just become that much more of a replaceable cog in the machine.
[+] [-] seanmcdirmid|6 years ago|reply
Autocomplete is and was never about saving on typing. It is an aide to help you browse and navigate large namespaces, it doesn’t enable long names, it enables deep and vast libraries. The complaint then isn’t about some straw man class name, but about the 200+ methods that can be called on that class.
[+] [-] tolmasky|6 years ago|reply
That being said, even if I programmed with the intent of continuing to be syntactically correct during the entire process (which I do when I am editing an existing file usually), I still cannot stand autocomplete, or really anything beyond simple syntax highlighting, because I feel like everything about today's computing experience is yelling at me. Notifications constantly popping up, linters yelling about stuff I don't care about yet, and autocomplete acting like clippy telling me every possible method that starts with an S. I find it severely distracting. I wouldn't want Microsoft Word to tell me every verb that starts with "s" just because it knows that in this position of the sentence I must be typing a verb and I just hit an "s".
[+] [-] knubie|6 years ago|reply
[+] [-] gumby|6 years ago|reply
Incremental search is finally appearing in some browsers, bringing them into the 70s. But just as software itself has seemingly gotten slower as the machines have sped up, I feel like the interfaces have gotten significantly more cumbersome.
[+] [-] hota_mazi|6 years ago|reply
It's very tricky to get right and requires a lot of attention to detail in timings, human attention span, UX, and even psychology.
IDEA's auto completion is mostly good, in my experience, not sure if you've tried it.
> i can type "empty()" on the keyboard faster than I can look at a screen and choose "empty()" from a list,
Sure, but that's a five letter word with no camel case nor special symbols. Your observation stops applying very quickly as the code base grows.
Not mentioning that having to type all these letters and symbols (especially if you need to use the shift key) is pretty bad from a carpal tunnel standpoint.
[+] [-] jcelerier|6 years ago|reply
I just checked my key sequence for writing that :
At no point I had to "choose" from a list from screen - if I have to I just type the next letter until what I want is accessible under <enter>.It's most certainly faster for me to press a single enter when it does than the four remaining letters, and the parentheses
[+] [-] lubujackson|6 years ago|reply
But I grew up coding in Notepad, so most editors feel like another part of the complexity stack I have to manage. Other devs seem to code with autocomplete almost like they are coding with a visual programming language. They use the mouse a lot more or keyboard combos if they are really efficient, but they anticipate autocomplete results and select variable names quickly, partly with a mental inventory of variable name options.
I think there are clear strengths to both methods. Pro-autocomplete devs seem to naturally follow the single responsibility principle (SRP) while I find that level of scaffolding obscuring at times.
[+] [-] jasonlotito|6 years ago|reply
I also don't know of a single language that requires auto-complete for everything. I do know languages that make more use of it, but I also don't now of a single language that benefits from not having some form of autocomplete. Even your myVector example could benefit from autocomplete (either having a better name them "myString" or "myInt" or me just typing 3 keys instead of 8 for completing myVector.
Do bad interfaces exist? Sure, I don't know of a single UI element that can't be done poorly or messed up.
[+] [-] baddox|6 years ago|reply
I suppose this is really just a matter of opinion, but it seems strange to argue that autocomplete is bad because it can be so useful that you'll definitely want to use it. Sure, it's a separate argument whether "Factory" and "Bean" are useful, but long, verbose, meaningful names are good in my opinion. A random example taken from the React source code: `attemptHydrationAtCurrentPriority`.
[+] [-] melling|6 years ago|reply
https://www.ibiblio.org/john_henry/
Just bang away at keyboard as fast as you can, hitting keys tens of millions of times over a lifetime.
Humans are tool builders. At some point, the tools will mature to the point where sudden bursts of typing at 100 wpm will become irrelevant.
[+] [-] eitland|6 years ago|reply
How about everyone with less than two years experience with both IDEs and editors stand back so we grown ups can sort this out ;-)
On a more serious note and as someone who has been on both sides of the fence:
How about we accept that people are different? Some people like Mac, some like Linux and some - gasp - enjoy their Windows desktop.
That said, and as someone who has extensive experience from both sides, I think that if people put the same effort into learning and configuring their IDE as they put in learning and configuring vim then that might very increase productivity a lot more than last ten years worship of vim.
(And: do learn a bit of vim. It comes in really handy sometimes, just don't fall for the idea that some people sell that you cannot become a good developer without using it all the time.)
[+] [-] sk0g|6 years ago|reply
For example, `err.nn` expands to ``` if err != nil {
} ```
And that's a default for GoLand. I have set up a few custom ones that are pretty handy as well, which frees up time from typing, to actually thinking through and solving problems, as well as making any necessary verbosity easier to deal with.
While most variable names are kept short, I do go for 2-3 word variables when necessary, and have some pretty long winded function names that, IMO, improve readability by a mile, like `GetNonEmptySliceElements()`.
[+] [-] wavefunction|6 years ago|reply
If you could customize the lag after ceasing to type a key and match it to your normal typing cadence I imagine your experience and utility from IDE autocomplete would be much greater.
[+] [-] edwinyzh|6 years ago|reply
[+] [-] reaperducer|6 years ago|reply
I treat it like eye candy: Just some fun, animated blandishment that makes me feel all 1337 while banging out code.
What would be nice is if the auto-complete window could be detached from the cursor and float in a corner of the editor, so I can look at it for those times when I have a brain fart and can't remember which parameter comes first in a function.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] city41|6 years ago|reply
[+] [-] gravypod|6 years ago|reply
Just recently I've been trying to use Bazel for for a personal project. When you use gRPC you don't get any auto completions on generated code. I haven't been able to locate anyone who cares about this because they use some text editor configuration that doesn't have autocompletion so this is basically never going to get fixed or have traction.
If more people prioritized type hinting and IDE friendliness I feel a lot of interesting tools would take off
[+] [-] ktpsns|6 years ago|reply
My feeling is that we experience a revival of keyboard-based searchable/explorable GUIs due to two reasons:
(1.) Many people use notebooks where both hands rest on the keyboard (in contrast to an external mouse where one hand permanently rests).
(2.) Desktop searches, or virtually any kind of search with a fast index took over (clearly pioneered by Apples Spotlight). That's the Google spirit of searching for things instead of clicking menus.
This is probably one of the changes where in the retrospective we can say "the 2010s" brought us. :-)
[+] [-] carreau|6 years ago|reply
Thanks to you (and the author) for being happy users of IPython; but if you don't have complaints you are not using it enough :-) We do our best to provide good completion; but most of the work is thanks to Jedi (Dave Halter) for the completion and prompt_toolkit (Jonathan Slenders) for the UI , at least in terminal.
There is a lot of improvement that could be done to completion (time and funding missing), and we are always looking for Feedback and Pull Requests.
Side Note while I agree about the statement about Julia and bar(foo) vs foo.bar(); nothing prevent the completer to add text not at the cursor position. Having foo)<tab> suggesting to prepend `bar(` is a possibility.
(also hijacking top comment...)
[+] [-] zitterbewegung|6 years ago|reply
https://github.com/emacs-helm/helm
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] bewuethr|6 years ago|reply
This means that if I hit tab for the first time, Bash will autocomplete as far as the completion isn't ambiguous; single keypress, no history pollution.
If I then hit tab again, I get a list of the possible completions.
The other single biggest improvement over default behaviour for me is this:
This will make the list of completions omit the part they all have in common.The combined behaviour is then like this: for a directory with a few files,
I can start typing: Now, hitting tab (just once) gets me the unambiguous part: Hitting it again shows me the possible completions with the common part replaced by an ellipsis:[+] [-] MadWombat|6 years ago|reply
Actually, this, coupled with the "complete on first tab hit" is the reason I stayed away from zsh. I tried it a few times, simply because so many people are raving about how much better it is than bash, but never really switched and the autocomplete is one of the major reasons.
1. I like to see autocomplete as a history. I hit tab (twice, but I will get to that in a second) and see what my options are. I type another letter or a few and hit tab again. If I made a mistake, I can catch it by comparing the previous set of choices to the new one. With zsh, if I made a typo, all I get is an empty list and a sense of confusion.
2. Every once in a while (more often than I a willing to admit), I will hit tab for completion when I don't really mean to. Like I will type something like ls -l /usr/local/bin/<TAB>. Bash will beep at me to ask if I am really sure. Zsh will freeze and compile a list of hundreds of completions. Not much else to say about that.
[+] [-] martopix|6 years ago|reply
[+] [-] emilfihlman|6 years ago|reply
[+] [-] jefftk|6 years ago|reply
[+] [-] jussij|6 years ago|reply
https://github.com/davidhalter/jedi
[+] [-] totalperspectiv|6 years ago|reply
Or maybe I'm just trying to justify why I use vim...
[+] [-] PaulDavisThe1st|6 years ago|reply
I'm sure one could set up some automatic completions-generating target in a build system that could be fed into an IDE. Well, I'd certainly hope so. But emacs' dynamic completion works so well for me, with no work to get the full benefit no matter what I'm writing - code, a letter, financial docs, anything at all where I just want to hit Ctrl-/ to finish off that slightly-longer than usual term that I just used a few lines earlier.
Yum.
[+] [-] Andrex|6 years ago|reply
Anecdotally, I hide the header in Google Docs/Sheets most of the time to save space, and have come to rely on the Menu Search field in the upper left (Alt+/, which works regardless of whether the header is shown) for things like renaming the doc, accessing conditional formatting, etc. Basically the few commands I use regularly which don't have a corresponding hotkey.
[+] [-] melling|6 years ago|reply
https://news.ycombinator.com/item?id=10285140
[+] [-] aliceryhl|6 years ago|reply
[+] [-] pletnes|6 years ago|reply
[+] [-] flyinglizard|6 years ago|reply
The best I’ve seen in this regard of discovering hidden things is the Visual Studio C# auto suggestions which refractors your code to use modern language features. It’s quite magical, sometimes doing non-trivial refactors.
I find it a great way to get exposed to the ongoing evolution of C# without actively polling the language spec.
[+] [-] jen20|6 years ago|reply
[+] [-] kuon|6 years ago|reply
[+] [-] williamvds|6 years ago|reply
[+] [-] jrochkind1|6 years ago|reply
This may be true as an effect. But these features in ObjC language (named arguments) and idioms (using them a lot, with verbose symbol names) both date from NextSTEP days, when the developer tool market was entirely different, and I doubt these language features were chosen with any thought whatsoever to this goal.
The author may not be implying otherwise, but some readers may take it that way.
From what I remember of the era, I think the motivations were more about clarity, and maybe some desire to "make code closer to human language." Why make class or method or argument or variable names cryptic abbreviations, when you can just spell them out? Won't this make the code much more readable and comprehensible, and as they knew then as well as now, code will be read many more times than it will be written.
Ruby idioms still lean in the direction of verbosity in symbol naming; perhaps both ruby and ObjC got it from smalltalk, a heavy influence to both. Which is interesting, because smalltalk also famously traditionally locks you into a particular difficult-to-write-an-alternative development environment; but at the time and place the choices were made that led to that, it also surely was not a "commercial" decision.
[+] [-] wooptoo|6 years ago|reply
[+] [-] gwbas1c|6 years ago|reply
It's not just memorizing: When working with a new or unfamiliar API, it's very easy to guess and navigate this way.
To be quite honest, when I work in environments without autocomplete, I feel like I'm learning slower then when I learn in Microsoft Visual Studio.
[+] [-] utxaa|6 years ago|reply
[+] [-] Stratoscope|6 years ago|reply
The Quick Tabs extension gives you autocomplete for Chrome tab titles:
https://chrome.google.com/webstore/detail/quick-tabs/jnjfein...
Just type Ctrl+Q and you get a popup with IntelliJ-style autocomplete.
Another trick for Chrome tabs (unrelated to autocomplete) is to open a new window instead of a new tab when starting a new task. If I'm searching for information about a particular programming topic, I use Ctrl+N and do the search in a new window, then Ctrl+click or middle button click to open interesting search search results in new tabs in that window. Then when I'm done I can close that whole batch of tabs at once.
This may seem like an obvious thing to do, but I have seen people who never open a second Chrome window but just have dozens of unrelated tabs in the same window.
[+] [-] eitland|6 years ago|reply
And, to be fair I thought Chrome had copied the Awesomebar by now?
[+] [-] arkh|6 years ago|reply
Early php did something like that just not for the same reason. https://news-web.php.net/php.internals/70691