Autocomplete as an Interface (2015)
You know, I realize I&#x27;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&#x27;s too much visual noise, too distracting. It&#x27;s a thing that pops up that demands your attention. If I want to type<p><pre><code>    if (myVector-&gt;empty()) { 
        fillVector(myVector); 
    }
</code></pre>
autocomplete will pop up a window like 4 times while writing. For no real reason: i can type &quot;empty()&quot; on the keyboard faster than I can look at a screen and choose &quot;empty()&quot; from a list, and having having the list pop up is distracting.<p>In fact, I <i>strongly</i> disagree with this:<p>&gt; 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.<p>Ugh, no, I don&#x27;t like this at all. This is what leads to nightmarish Java type names (&quot;AbstractSingletonProxyFactoryBean&quot;) 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.