Live data from Hacker News

Autocomplete as an Interface (2015)

benkuhn.net

141–150 of 197 posts

Re: Autocomplete as an Interface (2015)

#141
post #23

Earlier quoted context omitted.

IPython dev here, Thanks to you (and the author) for being happy users of IPython; but if you don't have complaints you are not using it enough :-) We do our best to provide good completion; but most of the work is thanks to Jedi (Dave Halter) for the completion and prompt_toolkit (Jonathan Slenders) for the UI , at least in terminal. There is a lot of improvement that could be done to completion (time and funding mi…

> if you don't have complaints you are not using it enough I'm a daily user. I wish there were a way to enable the autocomplete and doc display that ptipython has. In both the terminal and jupyter it would be very helpful.

Thanks for the feedback,

In JupyterLab you can open the "Inspector" that should have the equivalent and show the doc for the current token under cursor.

I'd love to have time to implement that for IPython, or even have for the completer the documentation that pops up for the current highlighted option of the completer.

As IPython is now based on Prompt toolkit there is no reason not to have that; it's mostly a question of finding the time to implement it !

Re: Autocomplete as an Interface (2015)

#142
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…

You're doing it wrong.

The way most people use it is they type enough letters to be specific enough then hit tab to fill in the rest.

For example in intellij I'd type something like "my" then hit tab immediately.

Re: Autocomplete as an Interface (2015)

#143

Earlier quoted context omitted.

What's often missing from these discussions is the impact on human memory. Back when I started programming, I never used syntax highlighting. It just wasn't a thing for a large part of my early years. Text mode VisualBasic and QuickBasic didn't have it. Nor did GW-BASIC, QuickC, Pascal, I could go on... I was at the point where I could write C code and have it compile the first time. No syntax errors, no compiler err…

I tend to agree with this line of thinking. I've been almost exclusively a Vim user for the past 15 years and feel like, if anything, it's made me a better programmer because I do spend a lot of time reading docs and code, refining my mental model of APIs, and often, thinking through problems before I start typing since I know that all of the characters in the file will come from strokes of my fingers. There are cert…

In what way does vim help here? It has all kinds of Syntax highlighting and autocompletion, and it's not like you can't disable it in other browsers.

Re: Autocomplete as an Interface (2015)

#144

Earlier quoted context omitted.

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.

Yeah, really! Who would want to read the docs of a library!?

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)

#145

Earlier quoted context omitted.

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.

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?

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)

#146
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…

What's often missing from these discussions is the impact on human memory. Back when I started programming, I never used syntax highlighting. It just wasn't a thing for a large part of my early years. Text mode VisualBasic and QuickBasic didn't have it. Nor did GW-BASIC, QuickC, Pascal, I could go on... I was at the point where I could write C code and have it compile the first time. No syntax errors, no compiler err…

Not only this -- but it renders you quite useless if you ever have to use a different environment. Sometimes that's because you have to use a different language that doesn't have as much tooling, sometimes its because a product gets discontinued, or your employer forces a different IDE, etc.

I definitely had this experience with CodeWarrior back in the day. I really loved that IDE. But then when Mac OS X came out and Objective-C became the native language, the tools weren't there yet, and I had to either program "alone" without autocomplete/fancy dynamic highlighting/etc, or use Project Builder (the predecessor to Xcode), which was lacking in all these departments. I found myself much slower, and not for the obvious reason of "of course, I'm missing all these great tools", but as you say, slower at things I knew I used to be fast at. It's kind of like discovering that no, you don't like broccoli, you actually just like the melted cheese on top. That was a big moment for me deciding to focus on generally applicable skills vs. IDE-specific skills.

Interestingly enough, I think this legitimately doesn't apply to a lot of people because they spend most, if not all, their career in one domain. In that environment I think learning IDE-specific things makes a lot of sense. I discovered that this wasn't for me and move around a lot, so its nicer to not be dependent on those things.

Re: Autocomplete as an Interface (2015)

#148

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

This! I tried zsh after reading the article and it looks like I would probably end up with lots of subtle mistakes being autocompleted/corrected in.

Re: Autocomplete as an Interface (2015)

#149

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

My experience with python is that the autocomplete in the REPL is good enough (autocomplete would be better but I don't like the idea of depending on specialized editor configs so it's not worth it in my mind.) If you don't know what fields your classes are then maybe your code isn't organized or documented well or you should be using type hints.

For really messy javascript or things you don't know well autocomplete helps though.

Re: Autocomplete as an Interface (2015)

#150

Earlier quoted context omitted.

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.

Yeah, really! Who would want to read the docs of a library!?

I think you meant to ask who would want to memorize the docs and never ever need confirmation they are remembering correctly?
Post reply on HN