[seanmcdirmid]

Auto completion has always worked well as a way to discover methods, not as a way of writing code. It’s like…”so where can I go when I’m here?” without having to pour over a bunch of API docs. No one ever presses the “I’m feeling lucky button” on the auto complete suggestions unless it’s an API they recognize.

I get the feeling that co-pilot wasn’t really designed with usability in mind, more like it was just a cool thing that could be done with a large code corpus and good machine learning techniques. If they could redo it as a mechanism for discovery somehow, it would be much more useful. But I’m not sure how to do that here, perhaps ranking completable methods based on a statistical likelihood that the user will want to use them (but then we start hitting Hick’s law where sorting by name is super important).

[rendall]

> Auto completion has always worked well as a way to discover methods

I think that was exactly the criticism in the article, though, that discovery via IDE is limiting, and for many developers this method of discovery supercedes actually reading documentation. I'm not sure he's wrong.

[setr]

Just from a visual efficiency measure, it’s a good steeping stone between discovery and actual docs, especially if the autocomplete also includes the first bit of description - most functions of an API are quite obvious, and ideally aren’t doing anything surprising in them anyways that the name + minidisc would actually lead you astray.

Of course, a stepping stone , at the end of the day you still need to understand the core model and operations — but then you’re just dealing with age-old problem of RTFM; a problem that has existed long before autocomplete’s general availability, and long after. The only real change autocomplete brings in that regard is that people might accidentally read something while scanning a manual for the API calls… but that’s really never been good enough anyways, so it’s not much of a loss

[seanmcdirmid]

Auto completion also has the perverse effect of APIs developers relying on its existence to build large APIs that would be hard to use without autocomplete. I once counted 232 methods for a UI button in Java available through the auto complete menu. There is just no way to use that API by RTFMing, but with auto complete, you can just search for what you need as you need it.

Alot do the reason Java is the way it is is probably because auto completion gained in popularity at the same time it did.

[theshrike79]

I use multiple languages every day. I can't be arsed to memorize whether the length of an array in this language was .length or .size or something else. And IDE helps me with that.

If myArray.l... doesn't autocomplete, I'll try with myArray.s... Compared to opening a browser and browsing through the language API docs it's exponentially faster.

[hocuspocus]

Maybe it's limiting but in practice are you going to read up about the hundreds or thousands of symbols exported by every library you're using in a project? There's only so much time you can spend reading documentation (when it exists) or books.