
Autocomplete as an Interface (2015) - fanf2
https://www.benkuhn.net/autocomplete
======
OskarS
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.

~~~
cytzol
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!

~~~
bo1024
It sounds like you're using autocomplete as a substitute for a tool you'd
like, but doesn't exist.

~~~
ses1984
Yes: what I really want is an autocomplete wired directly into my brain. Then
I just have to intend to start working and my code writes itself, without
having to lift a finger.

~~~
lubujackson
Welcome to the management track!

------
gravypod
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

~~~
bhaak
> 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.

They are not very well versed in vim if they don't know about the autocomplete
capabilities of it.

The most basic form is matching with ctrl-n in insert mode.
[http://vimdoc.sourceforge.net/htmldoc/insert.html#i_CTRL-N](http://vimdoc.sourceforge.net/htmldoc/insert.html#i_CTRL-N)

This can be beefed up by coupling it with ctags and even goes up to 11 with
full language server protocol support by using coc.nvim.

Never let anyone tell you can't do that in vim. Most of the time, they are
wrong.

~~~
afarrell
Vim can be used to do that, but not by me. After 12 years of using vim through
MIT and various software engineering jobs, I've accepted that it would take a
person of my mental abilities waaaaaay too long to set up.

Or, can you recommend a good book on vim package management and debugging?

~~~
bhaak
In my experience, there are people that like building their development from
the bottom up and others like going from top down.

It's perfectly fine to get a full featured IDE. If you miss the vi stuff, most
IDEs nowadays have pretty good vim emulations (and thanks to to neovim, many
have even perfect vim emulations).

Nevertheless, for an intro into vim plugin management, a good book is "Modern
Vim by Drew Neil".

~~~
afarrell
> "Modern Vim by Drew Neil"

I took a look at that on Amazon[1], but the reviews seem to indicate that it
gives a surface-level walkthrough of some of the available plugins. I'd need
something that gives me a mental model I can use for debugging.

[1] [https://www.amazon.co.uk/dp/B07DFBWVMB/ref=dp-kindle-
redirec...](https://www.amazon.co.uk/dp/B07DFBWVMB/ref=dp-kindle-
redirect?_encoding=UTF8&btkr=1)

------
ktpsns
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. :-)

~~~
carreau
IPython dev here,

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...)

~~~
j88439h84
> if you don't have complaints you are not using it enough

I'm a daily user. I wish there were a way to enable the autocomplete and doc
display that ptipython has. In both the terminal and jupyter it would be very
helpful.

~~~
carreau
Thanks for the feedback,

In JupyterLab you can open the "Inspector" that should have the equivalent and
show the doc for the current token under cursor.

I'd love to have time to implement that for IPython, or even have for the
completer the documentation that pops up for the current highlighted option of
the completer.

As IPython is now based on Prompt toolkit there is no reason not to have that;
it's mostly a question of finding the time to implement it !

------
bewuethr
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:

    
    
      $ cat file
      ...1  ...2  ...3
      $ cat file

------
MadWombat
> 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.

~~~
seb314
> I like to see autocomplete as a history

Not sure if I understand correctly:

Ctrl-r shows command history, filtered by fzf as you type

I find that particularly useful for frequent stuff that I don't bother to put
in a script. Optionally add some search keywords in a trailing comment.

(might be not zsh itself, but oh-my-zsh or so)

~~~
MadWombat
If you press tab twice in bash, it will display a list of completions and then
another prompt below. If you hit tab again, it will generate another list of
completions and another prompt. You should be able to still see the previous
list of completions above. Zsh reuses the prompt and redraws the completion
list, so once I hit tab, I cannot see what my previous completion list looked
like.

------
martopix
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.

~~~
leppr
The downside of TabNine is that it removes predictability. With regular
completion, semantic or not, if I have a long function name I can reliably
write a couple letters of it and get the completion without even having to
look at the suggestions.

~~~
martopix
One thing doesn't exclude the other. TabNine also supports semantic
completion. I haven't yet tried it in PyCharm, but I don't think it entirely
overrides the powerful built-in autocompleter.

------
emilfihlman
While IPython is cool, lets not forget autocomplete exists even in the default
python interpreter

    
    
      Python 3.5.3 (default, Sep 27 2018, 17:25:39)
      [GCC 6.3.0 20170516] on linux
      Type "help", "copyright", "credits" or "license" for more information.
      >>> s=""
      >>> s.[TABTAB]
      s.__add__(           s.__getattribute__(  s.__lt__(            s.__rmul__(          s.encode(            s.isdecimal(         s.join(              s.rjust(             s.title(
      s.__class__(         s.__getitem__(       s.__mod__(           s.__setattr__(       s.endswith(          s.isdigit(           s.ljust(             s.rpartition(        s.translate(
      s.__contains__(      s.__getnewargs__(    s.__mul__(           s.__sizeof__(        s.expandtabs(        s.isidentifier(      s.lower(             s.rsplit(            s.upper(
      s.__delattr__(       s.__gt__(            s.__ne__(            s.__str__(           s.find(              s.islower(           s.lstrip(            s.rstrip(            s.zfill(
      s.__dir__(           s.__hash__(          s.__new__(           s.__subclasshook__(  s.format(            s.isnumeric(         s.maketrans(         s.split(
      s.__doc__            s.__init__(          s.__reduce__(        s.capitalize(        s.format_map(        s.isprintable(       s.partition(         s.splitlines(
      s.__eq__(            s.__iter__(          s.__reduce_ex__(     s.casefold(          s.index(             s.isspace(           s.replace(           s.startswith(
      s.__format__(        s.__le__(            s.__repr__(          s.center(            s.isalnum(           s.istitle(           s.rfind(             s.strip(
      s.__ge__(            s.__len__(           s.__rmod__(          s.count(             s.isalpha(           s.isupper(           s.rindex(            s.swapcase(
      >>>

~~~
jefftk
That's the case now, but it wasn't in 2015 when this post was published.

~~~
duckerude
It seems to be enabled by default since 2013/Python 3.4:

[https://bugs.python.org/issue5845](https://bugs.python.org/issue5845)

[https://github.com/python/cpython/commit/1a6cb30a346ba8812d6...](https://github.com/python/cpython/commit/1a6cb30a346ba8812d6abc77fddee636ae06ccff)

[https://docs.python.org/3.4/whatsnew/3.4.html#sys](https://docs.python.org/3.4/whatsnew/3.4.html#sys)

Support already existed in Python 2, so it's sad that it took so long for it
to be enabled by default.

------
totalperspectiv
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...

~~~
vbezhenar
The most significant difference in my experience is with dynamically typed
languages. I started to write some code in Lua in a simple editor. It worked,
but I was very slow, because I made many silly mistakes, mostly typos or
trivial errors and those manifested only at runtime, requiring full restart of
an application and repeating all actions until that code is run. Then I
switched to IDE which highlighted silly errors and allowed autocomplete which
eliminated typos and my productivity was few times better. I'm sure that it'll
be the same with JavaScript or Python.

~~~
swiley
My experience with python is that the autocomplete in the REPL is good enough
(autocomplete would be better but I don't like the idea of depending on
specialized editor configs so it's not worth it in my mind.) If you don't know
what fields your classes are then maybe your code isn't organized or
documented well or you should be using type hints.

For really messy javascript or things you don't know well autocomplete helps
though.

------
PaulDavisThe1st
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.

Yum.

------
Andrex
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.

------
melling
Prior 2015 discussion with good comments:

[https://news.ycombinator.com/item?id=10285140](https://news.ycombinator.com/item?id=10285140)

------
aliceryhl
It's not just how zsh displays the completions. The fact that I can complete
from the middle of the filename is quite important to me.

~~~
pletnes
Yep. Also the fact that it can complete in more places. Git history, remote
hosts for ssh, ...

~~~
hnlmorg
In fairness Bash can do that as well. It's not a shell specific thing,
autocompletion is just a shell script after all, the issue is whether someone
has written those scripts (which they have for Bash) and if your package
manager ships them (which some do but others do not).

However I do agree that Bash generally feels outdated these days. In fact
autocompletion was the primary reason behind me writing my own readline API

~~~
pletnes
In my experience, this is partly true but in general it’s hard to get it to
work well and in the end zsh is more slick. Xonsh is another shell that also
has better completion than bash and with even less effort. (It’s not as stable
though...)

~~~
hnlmorg
I agree that there are plenty of shells which make it easier to write
completion scripts (even I've written one which would fall into that category)
and there are plenty of shells and 3rd party libraries which provide a nice
UI/UX for autocompletion than readline does.

... _however_ Bash can still do the items you'd described earlier. In fact
back when Bash was my primary shell (which is a few years ago now), it
literally did do those things you described and it came already pre-written as
part of whatever Linux package I was using. ie I didn't have to write those
scripts myself.

But yes, I do agree Bash is pretty horrible at writing and using
autocompletion compared to more recent shells. There no doubt about that :)

------
flyinglizard
> 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.

~~~
jen20
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!

------
kuon
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.

~~~
L_Rahman
Fish autocomplete when navigating directory trees is a life changing thing.

~~~
utxaa
this is so interesting. i kid you not, as soon as fish starts doing its thing
my brain shuts down. i cannot use it not even for a minute. i've tried. i had
to try because the assholes where i work forced it on me. so i threatened to
quit. it worked ;) ... back to good ole bash.

------
williamvds
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

------
jrochkind1
> 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.

------
wooptoo
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.

------
gwbas1c
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.

~~~
utxaa
mostly i don't like autocomplete. but MVS implementation is superb. the
closest i've seen to something usable (for me).

------
Stratoscope
> _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:

[https://chrome.google.com/webstore/detail/quick-
tabs/jnjfein...](https://chrome.google.com/webstore/detail/quick-
tabs/jnjfeinjfmenlddahdjdmgpbokiacbbb)

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
400 tabs in Firefox. No special plug-in. No problem.

And, to be fair I thought Chrome had copied the Awesomebar by now?

~~~
utxaa
:D

------
arkh
> 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.

Early php did something like that just not for the same reason. [https://news-
web.php.net/php.internals/70691](https://news-web.php.net/php.internals/70691)

------
pcr910303
Autocomplete, IMO is a crude effort to make text based interfaces more
interactive.

While it does address some shortcomings of text based interfaces, text based
interfaces are inherently flawed to provide enough feedback or context to the
user. The only reason we are still using text based interfaces is that the
computing system has revolved around UNIX and the command line.

The fact that autocomplete is needed for sanely using text based interfaces
(especially the command line and programming languages) are proving that we
need a better interface.

GUIs became popular due to providing the users instant feedback of what the
user can and cannot do, providing context implicitly with the user interface
elements. Autocomplete's corresponding features are flag/function name
completion, context (like the current directory) based completion... but they
really don't do their job well.

I do not have any ideas about what the interfaces of the future will be... but
text based interfaces won't be the future. Hence autocomplete might become
obsolete...

<Sorry for the useless rant :-(>

~~~
cloverich
Text is generic. With interfaces you have to design abstractions that are
suited to the application. Like code, great UI abstractions make solving
problems easier and pleasant. Wrong abstractions do the opposite, leaving
users powerless to accomplish their goals. Text both fills a gap for when no
abstraction is present and provides a fallback when the abstraction isn't good
enough or discoverable.

------
buboard
C got this right. We tend to resort to textual interfaces (CLIs and source
code, searching instead of directories) because they have the expressivity and
conciseness of language. No other tool such as Diagram languages works as
good. As devs , our tools are keyboards and our eyes. The measurable goal is
to reduce the time it takes to type and read code. Autocomplete makes code too
verbose, keyboard makes it too cryptic. I tend to err towards brevoty, as i
think it s important to be able to read code in large chunks fast. As such i
think autocomplete is mostly annoying as it gets in the way. Languages should
instead be laconic even if that means a little memorizing. I think C or python
get the balance right and that should have a measurable productivity benefit

------
shusson
> I can point to exactly one tool that has approximately doubled my
> programming speed, and that’s the IPython notebook

My biggest issue with IPython notebooks is that it holds state between cells.
Sure it makes things faster, but it also lends itself to bad programming
techniques.

------
celeritascelery
I am glad to see emacs mentioned. One of the cool things about it is that you
can have completion your way. For example I made a package for when you are
running shells in emacs it will send a tab character and then intercept the
output. Then it displays it in an emacs pop up. Completely bypasses the issue
of bash adding new prompts with every tab.

[https://github.com/CeleritasCelery/emacs-native-shell-
comple...](https://github.com/CeleritasCelery/emacs-native-shell-complete)

------
bulletloaf
Along the same lines, I've been thinking a lot lately about how I'd love to
have a voice recognition equivalent of a CLI. I see this as almost the only
way to truly get away from keyboards.

Imagine how efficient is is to type "kubectl get pod my_pod" versus clicking
around in a clunky web-based dashboard. Now imagine if your smart speaker's
set of commands were as strict or well documented as most CLI apps.

~~~
bmgxyz
I can't decide whether or not I like this idea. I feel like it would be weird
to speak code into a computer, but maybe that's just because I don't already
do it. It would be neat if it worked, though. Having played around with voice
recognition before, I don't have a lot of confidence that the current state of
the art could handle the precision required for code.

Now, if there were a way to use the same technology with [subvocal
recognition]([https://en.wikipedia.org/wiki/Subvocal_recognition](https://en.wikipedia.org/wiki/Subvocal_recognition)),
that would really be something. I'd be onboard with more or less thinking my
code and watching it appear on the screen, since that's what I do now, just
with a few finger steps in between.

------
haolez
I like how "script"[1] works - you can write really simple interactive
software and let script do the autocomplete and reverse lookup for you. Rob
Pike even uses it in some of his presentations.

[1][http://man7.org/linux/man-
pages/man1/script.1.html](http://man7.org/linux/man-pages/man1/script.1.html)

------
keehun
The one major issue with autocomplete is that—like with anything else in
life—if you become too dependent on it, you will be crippled if (for whatever
reason) the IDE or the autocomplete feature fails for any percentage of the
time.

I speak from personal experience as this happens regularly in Xcode for large
iOS projects. Xcode is notorious for its fragile indexing system. Symbols are
often not correctly picked up, and autocomplete is notoriously unreliable when
the projects get large. This happened often enough that it actually trained me
to become much more comfortable writing code for long periods of time without
relying on autocomplete at all.

If autocomplete/IDE indexing system lags behind or is unavailable for even
0.5% of the time, that translates to real time where the developer is waiting
for the autocomplete list to appear.

With Python, Ruby, and other languages, one has a plethora of
IDEs/editors/environments to choose from. However for Objective-C or Swift,
the environment is severely limited. AppCode does exist, and it does have a
much better indexer and autocomplete, but it is very different than Xcode and
most iOS developers will not be able/willing to move to AppCode. And that's
even before considering their licensing costs.

With most helpful aids, I would say that autocomplete is a gift and useful
day-to-day, but to make it a central dependency during the development phase
seems to be a mistake.

------
useful
Autocomplete is the first step. Then you get linting, static analysis,
autoformat on save, and code snippets. All built into your fancy IDE with
plugins. You are super productive, you learn from its suggestions that you can
quickly flip through, and your coworkers are happy that they only have to
check your code for correctness and implementation, not style and edge cases.

~~~
utxaa
this is like the self driving car myth. i just don't think computation extends
this far. ie, a computer cannot do math in the sense of the
[https://en.wikipedia.org/wiki/Entscheidungsproblem](https://en.wikipedia.org/wiki/Entscheidungsproblem)

~~~
cdo256
If you're referring to formal verification tools (which help programmers
mathematically prove that their program has certain properties). Then it
doesn't need to extend into all the edge cases. Usually if the machine tells
you it can't create a proof you add more checks to your code or pick the
properties so that they're easy to prove. There's no need for completeness.

If you're referring to anything your parent mentioned, those tools already
exist.

------
nikisweeting
My 3 most life-changing developer tools are the Fish shell (because of its
autocomplete), the TabNine autocomplete plugin, and a clipboard history
manager which is essentially system-wide autocomplete.

------
Lightbody
So much this!

Autocomplete in early versions of IntelliJ IDEA and NetBeans is basically how
I learned to _really_ program Java. After a 10 year break from serious coding,
it's also how I caught back up :)

~~~
AnimalMuppet
Autocomplete in IntelliJ was almost like being psychic. With very little
typing, the code just magically appeared on the screen.

------
tekknolagi
Based on the title, I thought this article would be about creating a context-
sensitive API for generating autocompletions in some programming context. Like
a Python API, etc.

------
sicromoft
Mods: can you add [2015] to the title?

~~~
dang
Done now.

