Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Autocomplete as an Interface (2015)

benkuhn.net

Post reply on HN
Print view View original

31–40 of 197 posts

Re: Autocomplete as an Interface (2015)

#31

Post by kristjansson »

MadWombat wrote: post #25

> 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 autocompl…

> zsh will freeze and compile a list of hundreds

Recent zsh will (configurably) ask if you really want completion it detects there will be more than a smallish number of candidates

Still a pain for other completion sources though

Re: Autocomplete as an Interface (2015)

#32

Post by jasonlotito »

OskarS wrote: post #20

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 t…

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.

Re: Autocomplete as an Interface (2015)

#33

Post by 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.

Re: Autocomplete as an Interface (2015)

#34

Post by manaskarekar »

jasonlotito wrote: post #32
OskarS wrote: post #20

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 t…

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…

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

That's a negative experience for me. If I'm pausing, it's because I need to think about something.

In that instant, a suggestion distracts me.

The chances of the suggestion being relevant to my pause are pretty low.

The best option is when you can invoke the autocomplete/docs on demand - using a convenient shortcut.

Re: Autocomplete as an Interface (2015)

#35

Post by OskarS »

SketchySeaBeast wrote: post #28
OskarS wrote: post #20

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 t…

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 w…

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

Re: Autocomplete as an Interface (2015)

#36

Post by bmgxyz »

bulletloaf wrote: post #24

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.

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

Re: Autocomplete as an Interface (2015)

#37

Post by namdnay »

OskarS wrote: post #20

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 t…

I think it depends which objects you're manipulating. I remember that autocomplete was the best thing since sliced bread when trying to manipulate UI objects in VB6

Re: Autocomplete as an Interface (2015)

#38

Post by 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...

Re: Autocomplete as an Interface (2015)

#39

Post by melling »

OskarS wrote: post #20

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 t…

There are lots of developers like yourself. I always refer to this as the John Henry Programmer.

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.

Re: Autocomplete as an Interface (2015)

#40

Post by cytzol »

OskarS wrote: post #20

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 t…

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

Post reply on HN