Autocomplete as an Interface (2015) • Hacker News Board

Re: Autocomplete as an Interface (2015)

#111

Post by [deleted] » Thu, Jan 16, 2020, 6:40 PM UTC

cytzol wrote: post #40

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, some…

[deleted]

Re: Autocomplete as an Interface (2015)

#112

Post by baddox » Thu, Jan 16, 2020, 6:40 PM UTC

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…

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

Re: Autocomplete as an Interface (2015)

#113

Post by vbezhenar » Thu, Jan 16, 2020, 6:42 PM UTC

totalperspectiv wrote: post #38

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

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.

Re: Autocomplete as an Interface (2015)

#114

Post by heck_i_am_wrong » Thu, Jan 16, 2020, 6:43 PM UTC

seanmcdirmid wrote: post #48

andai wrote: post #45

Earlier quoted context omitted.

Re: editor trying to be helpful but getting in the way Sublime Text often inserts "matching" quotes and parentheses. But it doesn't always do the right thing, so I usually have to go back and erase it. But then it erases the original one, too. So I have to move the cursor, add a space, and then erase it. And when the feature does do what I wanted, it's only saving me literally 1 character --- ~0.1 seconds at my typin…

It isn’t doing the quote matching to save on your typing, but to keep your scanner from providing the wrong tokens to the parser of your compiler that is running all the time while you are typing.

'Only' quoting: 'Serious visual noise'

'I think there are very real costs.'

First off all, "misuse" of autocomplete can be very annoying. Some autocomplete system autocompletes with you.

IN ORWELLS REALITY: It isn’t doing the quote matching to save on your typing, but to keep the scanner from providing the wrong tokens to the parser of a compiler that is running all the time while you are typing.

So... 'Human Interface' ? ^^

Re: Autocomplete as an Interface (2015)

#115

Post by thisgoodlife » Thu, Jan 16, 2020, 6:47 PM UTC

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…

Choosing an item from a list is not the right way to use autocomplete. IMHO, autocomplete is a good way to make sure you don't have typos. I never choose from a list. I always type enough letters to make sure the current one is the one I want and then hit tab.

Re: Autocomplete as an Interface (2015)

#116

Post by seanmcdirmid » Thu, Jan 16, 2020, 6:59 PM UTC

heck_i_am_wrong wrote: post #114

seanmcdirmid wrote: post #48

Earlier quoted context omitted.

It isn’t doing the quote matching to save on your typing, but to keep your scanner from providing the wrong tokens to the parser of your compiler that is running all the time while you are typing.

'Only' quoting: 'Serious visual noise' 'I think there are very real costs.' First off all, "misuse" of autocomplete can be very annoying. Some autocomplete system autocompletes with you. IN ORWELLS REALITY: It isn’t doing the quote matching to save on your typing, but to keep the scanner from providing the wrong tokens to the parser of a compiler that is running all the time while you are typing. So... 'Human Interfa…

If you want the compiler to be useful while you are typing, then the designers of your tooling have to do something. You can argue that they are doing the wrong thing, you can argue that having the compiler running while you are typing isn't worth it because you don't need the feedback, but don't misidentify why they are doing it; they aren't doing it to help you save a millisecond on typing, that isn't the concern at all.

Re: Autocomplete as an Interface (2015)

#117

Post by seanmcdirmid » Thu, Jan 16, 2020, 7:08 PM UTC

bo1024 wrote: post #72

cytzol wrote: post #40

Earlier quoted context omitted.

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, some…

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

Code completion (not auto complete) was always meant for discovery and never to help save on typing, at least in textual environments. The idea of immediately showing you what some symbol can do without using the mouse is very powerful.

Re: Autocomplete as an Interface (2015)

#118

Post by rohansingh » Thu, Jan 16, 2020, 7:09 PM UTC

gravypod wrote: post #15

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

Are you using gRPC with Go bindings? There is work underway for rules_go in Bazel to expose generated types like your gRPC and Protobuf classes.

You can follow this issue for updates: https://github.com/bazelbuild/rules_go/issues/512

Re: Autocomplete as an Interface (2015)

#119

Post by kall » Thu, Jan 16, 2020, 7:11 PM UTC

intrepidhero wrote: post #83

cytzol wrote: post #40

Earlier quoted context omitted.

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, some…

VB6 had a feature where if you typed a previously defined name with the incorrect case it would autocorrect it for you. I used to type my identifiers with purposely incorrect casing so that the autoformatter would confirm that I had selected the correct variable or method name. I really liked that feedback. Not that I'm saying that was a great workflow. But I liked the subtle feedback as I typed. I've also used autoc…

I rely on prettier (AST based JS+ formatter) in the same way. I intentionally add to little or too much space to get subtle feedback on if there is a syntax error in my (deeply nested) code.

Re: Autocomplete as an Interface (2015)

#120

Post by gumby » Thu, Jan 16, 2020, 7:26 PM UTC

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