Autocomplete as an interface, Hacker News

so I don’t have to.^{3The API writers could certainly use a lesson in concision. 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.}

On another few hands:

Blitting is a complex operation that needs to go really fast! If you want to blit something quickly you actually do need an eight-parameter method.

The reason we don’t usually need named parameters is that (a) there’s usually an obvious convention for the order that the parameters go in, so the programmer can guess the order; (b) if you mess up the order, the type system will usually catch your mistake. If you have eight integer parameters, both of these break down.

Even for methods with fewer arguments, transposing the order of two non-keyword arguments of is one of the easiest bugs to make and the hardest to catch in code review. I’ve worked at multiple companies where a bad enough bug could theoretically wipe out millions of dollars before anyone noticed. Keyword args aregreat.4

This style means that method names are largely self-documenting. Fewer documentation lookups means fewer context switches, which means faster programming. It also means that it’s easier to tell if a method is the one you wantfrom inside the autocomplete windowinstead of searching for it in the documentation, which reduces context-switching even more.

Trying to shorten names “to save typing” is one of the great scourges of interface design, because you end up switching between e.g.sourceand (src) Depending on how much they want to save space. Good autocomplete means you can implement an obvious rule: just don’t do that!

Ruthie often tells me that “keystrokes are cheap.” But Objective-C shows that this isn’t quite true, at least in big enough aggregate. Saving one or two keystrokes isn’t usually worth the trouble, but Xcode can save programmers tens of keystrokes per method call. By the tens or hundreds, keystroke costs do add up — both in terms of time spent typing, and of chance to make a typo that costs further time to correct and recompile. Removing that kind of cost is a big enough deal that it’s transformed how Objective-C interfaces are designed.before I discovered keyboard shortcuts, I used to spend a ton of time looking for things in menus. That’s why one of my favorite features in OS X is the search bar in the Help menu. In newer versions of OS X,⌘-⇧ – /(aka⌘ -?opens up the Help menu and plops your cursor in a search bar that can search through every menu item in the application:

The only reason I ever browse menus anymore is out of habit. (And because the search isn't quite as great as it could be — it can still be more efficient to use menus if you know exactly where your target is.) (⌘ -) for Spotlight serves a similar function for apps, files, and other miscellaneous computer objects, and it's replaced my need for the dock,

Gmail’s contact autocompletion means you barely even need to remember what your contact’s name is, let alone their email. Google search autocompletion means you don’t even need to know what you’re looking for — type in some vaguely relevant words and Google will guess what you mean.

And of course Emacs autocompletion deserves a special mention, especially as augmented by helm. I have 100 files open in emacs right now and I can find any particular one in five keystrokes. Imagine having 823 tabs open in Chrome — you could never find anything! With Emacs I don’t even need a tab bar because it’s so simple to autocomplete the buffer I need. In fact, I've set it up not to distinguish between files on disk and files that are already open — when I ask emacs “switch to this buffer” I'm really asking it “open this file (or show the buffer if it's already open). ”And it's still fast and seamless.^{(5) **********************}