News for hackers. Stuff that matters.
Re:Autocomplete as an Interface (2015) by cytzol on Thursday January 16, 2020 @10:48AM (#22065570)
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!

Re:Autocomplete as an Interface (2015) by bradstewart on Thursday January 16, 2020 @11:20AM (#22065962)
This. I find it's even more valuable with the explosion of 3rd-party libraries and packages--I'm constantly interfacing with code I didn't write, and autocomplete is _way_ faster than context switching to look at the docs/source of a library.
Re:Autocomplete as an Interface (2015) by aratakareigen on Thursday January 16, 2020 @04:16PM (#22069044)
Interesting, but why not just have the autocomplete as a pane on the side so that you can focus, in the 99% case where you do have a good grasp of your dependencies?
Re:Autocomplete as an Interface (2015) by bradstewart on Thursday January 16, 2020 @04:47PM (#22069333)
That would certainly be a viable middle ground, but I simply don't find the in-editor popup to be distracting. I find a good many things distracting while working, but I actually like the autocomplete popups.
Re:Autocomplete as an Interface (2015) by cdo256 on Friday January 17, 2020 @08:36AM (#22074471)
I don't think the main problem is that they're distracting, in the drawing attention away from what you're writing sense. I think the main problem is that, for an unfamiliar editor, the autocomplete takes an unknown subset of keystrokes, meaning that common things like inserting a newline or navigating vertically can interrupt your train of thought.

Once you get familiar with a particular editor then these problems become less acute. What remains is the obscuring of other lines of code which can be fixed by making the autocomplete box only appear when you press tab.

Re:Autocomplete as an Interface (2015) by jonhohle on Thursday January 16, 2020 @03:42PM (#22068667)
Yeah, really! Who would want to read the docs of a library!?
Re:Autocomplete as an Interface (2015) by scarface74 on Thursday January 16, 2020 @04:10PM (#22068970)
Re:Autocomplete as an Interface (2015) by omaranto on Thursday January 16, 2020 @05:41PM (#22069807)
I think you meant to ask who would want to memorize the docs and never ever need confirmation they are remembering correctly?
Re:Autocomplete as an Interface (2015) by bradstewart on Thursday January 16, 2020 @04:43PM (#22069296)
I always read the docs first. And then usually skim the source code (when available). But that doesn't mean I've memorized every method name and signature.
Re:Autocomplete as an Interface (2015) by ehnto on Thursday January 16, 2020 @11:07AM (#22065801)
> 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!

Exactly, autocomplete is an excellent discovery tool. I may not even be aware productModel->hasConfigurableOptions was a function, or Product\Model\Configurable\Options was a model until I check with autocompletes.

Re:Autocomplete as an Interface (2015) by intrepidhero on Thursday January 16, 2020 @12:26PM (#22066679)
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 autocompleters in the fashion you describe. Syntax highlighting can also provide this kind of feedback and I feel like these tools could probably morph into a single, more cohesive tool that provides a smoother experience than the pop-up window.

Re:Autocomplete as an Interface (2015) by kall on Thursday January 16, 2020 @02:11PM (#22067796)
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) by gfunk911 on Thursday January 16, 2020 @06:48PM (#22070356)
I do the exact same thing with Prettier. I get a little spark of joy every time my code snaps back into place :)
Re:Autocomplete as an Interface (2015) by bo1024 on Thursday January 16, 2020 @12:02PM (#22066404)
It sounds like you're using autocomplete as a substitute for a tool you'd like, but doesn't exist.
Re:Autocomplete as an Interface (2015) by ses1984 on Thursday January 16, 2020 @12:18PM (#22066592)
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.
Re:Autocomplete as an Interface (2015) by lubujackson on Thursday January 16, 2020 @12:59PM (#22067066)
Welcome to the management track!
Re:Autocomplete as an Interface (2015) by thedirt0115 on Thursday January 16, 2020 @12:15PM (#22066559)
Ok, I'm curious! What might such a tool look like or do? Did you have something specific in mind?
Re:Autocomplete as an Interface (2015) by cdo256 on Friday January 17, 2020 @08:55AM (#22074603)
I could imagine two tools: 1. A tool that parses the text and draws red underlines on all the errors, this exists but (at least for C++ in VS 2017) it is quite slow. 2. A tool that automatically populates and updates types of variables and functions.

Both of these could be achieved by somehow decoupling the front-end (as in before semantic analysis) of compilers and making them output the AST in some standardized tree-structured format like XML.

Re:Autocomplete as an Interface (2015) by dr_baba on Saturday January 18, 2020 @06:48AM (#22083893)
Doesn’t the Language Server Protocol already do this, just via JSON instead of XML? I believe at least some LSP backends (e.g. clangd) just reuse a compiler AST and feed the data to your editor?
Re:Autocomplete as an Interface (2015) by seanmcdirmid on Thursday January 16, 2020 @02:08PM (#22067761)
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) by deckard1 on Thursday January 16, 2020 @02:43PM (#22068108)
ehhh. Only if your API is incredibly simple. You still have to roughly know that some operation exists and what that likely name is for the operation. Otherwise you're scrolling through a list of hundreds or even thousands of possible matches.

If you know you have an array and you know what you want to do with that array but don't know the name of the operation you want to do with that array, then completion as a form of discover sucks. No one is likely to stumble upon, say, JS's ".some()" method without having prior knowledge that this function exists and have it do exactly what they want.

Re:Autocomplete as an Interface (2015) by seanmcdirmid on Thursday January 16, 2020 @02:52PM (#22068194)
Yes, you still have to know kind of how it was named and kind of how it was used. It is just the rest of the details you can forget (or likewise, don't need to remember). It is really useful when you have to use libraries that are kind of similar but not exactly.

Anecdotally, I use Typescript and code completion is exactly how I discovered Javascript's "some" and "every" methods. It involved lots of scrolling because I didn't know it would be named like that, but based on the presence of other list comprehension methods I had a good suspicion that they were there somewhere...I still often mistakenly write LINQ-named "all" and "any", but the online type checking quickly snaps me out of it. Code completion can actually be improved to deal with these cases with more utility, by not only matching on the parts of the member's name, but a system could also match on synonyms to parts of what you typed as well (or document aka's in the interface that play no other role than hooking into code completion).

Re:Autocomplete as an Interface (2015) by pushpop on Friday January 17, 2020 @01:40AM (#22072410)
Nobody is suggestion autocomplete replaces basic API knowledge, reading the docs, etc. What they’re saying is autocomplete saves having to remember every facet of the API precisely.

It’s like a rounded edge on plug pins, you still have to know where the plug socket is to plug something in but the rounded pins mean You don’t need to be millimetre perfect when inserting it because the plug will slide along the curve and guide itself into the socket.

That’s the point of autocomplete, it’s about enabling developers to focus on remembering the important stuff while the IDE helps guide them around the more granular bits that are still syntactically important to the compilation of software but don’t really matter to the logic you’re writing.

Re:Autocomplete as an Interface (2015) by seanmcdirmid on Friday January 17, 2020 @07:02AM (#22073933)
Code completion does replace a lot of doc use cases, like autocomplete in a shell reduces the need to go to man pages. But ya, code and auto completions are like HUDs for more structured experiences based around text editing.
Re:Autocomplete as an Interface (2015) by pushpop on Thursday January 16, 2020 @01:11PM (#22067191)
Shouldn’t the fact he’s using it and likes it be proof it exists and not a substitute tool?

In addition to his workflow, I want to add that I really appreciate having the parameters and types displayed when calling a function or method. Sometimes it’s unavoidable asking yourself questions like “which way round are those arguments?” or “is that a signed/unsigned integer?” Sure you can look at the code behind the function you want to call but having the IDE prompt that saves you navigating away from the code you’re currently writing. That’s a massive win for me. Particularly for projects that require less active development