News for hackers. Stuff that matters.
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