So much this!
Autocomplete in early versions of IntelliJ IDEA and NetBeans is basically how I learned to really program Java. After a 10 year break from serious coding, it's also how I caught back up :)
Autocomplete as an Interface (2015)
91–100 of 197 posts
Re: Autocomplete as an Interface (2015)
#92You 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…
> Ugh, no, I don't like this at all. This is what leads to nightmarish Java type names ("AbstractSingletonProxyFactoryBean") that makes this language practically demand auto-complete. You have it the wrong way around. Naming like that comes from the structure of the application, which just happens to benefit the ability for autocomplete tools to understand it. If you've ever worked on enterprise software, with hundre…
I don't think there's anything inevitable about AbstractSingletonProxyFactoryBean. This absurd design pattern has its roots in Java's misguidedly restrictive approach to abstraction, which all but requires classes and inheritance to be the primary units of abstraction. More graceful abstractions are unergonomic or impossible since Java was not designed e.g. for higher order functions. The requirement that everything be in a class and the ontological awkwardness that often ensues when some conceptually non-object-y entity must be coerced into an object results in a lot of incidental complexity.
Re: Autocomplete as an Interface (2015)
#93Earlier quoted context omitted.
I'd argue that it's not benign. I think there are very real costs. First off all, "misuse" of autocomplete can be very annoying. Some autocomplete system autocompletes when you press tab, some when you press enter. Many times I've been typing a thing, finished the line with the autocomplete window still open, pressed enter to go to the next line, and instead have auto-complete enter a bunch of stuff I don't want. The…
I personally see your first two arguments the exact opposite way. The visual display functions a bit like subtitles on TV: I don't really notice it's there, until it can help me. Just like subtitles help when I don't immediately understand something, autocomplete helps when typing something takes a bit longer than I'd like it to or when I'm not entirely sure what I want to write. The "misuse" of autocomplete always c…
Subtitles are very distracting for some, if they're on I I can't help it and end up reading instead of listening and watching the movie attentively.
I personally am in the affected by visual noise camp. But it appears that some aren't that bothered by it.
Re: Autocomplete as an Interface (2015)
#94You 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 almost always turn off autocomplete I treat it like eye candy: Just some fun, animated blandishment that makes me feel all 1337 while banging out code. What would be nice is if the auto-complete window could be detached from the cursor and float in a corner of the editor, so I can look at it for those times when I have a brain fart and can't remember which parameter comes first in a function.
Emacs + company + posframe to the rescue.
Re: Autocomplete as an Interface (2015)
#95Earlier quoted context omitted.
It sounds like you're using autocomplete as a substitute for a tool you'd like, but doesn't exist.
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.
Welcome to the management track!
Re: Autocomplete as an Interface (2015)
#96So much this! Autocomplete in early versions of IntelliJ IDEA and NetBeans is basically how I learned to really program Java. After a 10 year break from serious coding, it's also how I caught back up :)
Autocomplete in IntelliJ was almost like being psychic. With very little typing, the code just magically appeared on the screen.
Re: Autocomplete as an Interface (2015)
#97I could not agree more to this article. Not only am I a happy IPython and zsh user, but also like searchable menus (also refered to as "OSD search" or similar in non-Mac OS X contexts). My feeling is that we experience a revival of keyboard-based searchable/explorable GUIs due to two reasons: (1.) Many people use notebooks where both hands rest on the keyboard (in contrast to an external mouse where one hand permanen…
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…
One of the most jarring problems with ipython is scoping of list comprehensions. I loose access to certain objects while writing more elaborate list comps all the time. I'd be really happy if that got fixed at some point...
Re: Autocomplete as an Interface (2015)
#98Earlier 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.
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
Re: Autocomplete as an Interface (2015)
#99The one major issue with autocomplete is that—like with anything else in life—if you become too dependent on it, you will be crippled if (for whatever reason) the IDE or the autocomplete feature fails for any percentage of the time.
I speak from personal experience as this happens regularly in Xcode for large iOS projects. Xcode is notorious for its fragile indexing system. Symbols are often not correctly picked up, and autocomplete is notoriously unreliable when the projects get large. This happened often enough that it actually trained me to become much more comfortable writing code for long periods of time without relying on autocomplete at all.
If autocomplete/IDE indexing system lags behind or is unavailable for even 0.5% of the time, that translates to real time where the developer is waiting for the autocomplete list to appear.
With Python, Ruby, and other languages, one has a plethora of IDEs/editors/environments to choose from. However for Objective-C or Swift, the environment is severely limited. AppCode does exist, and it does have a much better indexer and autocomplete, but it is very different than Xcode and most iOS developers will not be able/willing to move to AppCode. And that's even before considering their licensing costs.
With most helpful aids, I would say that autocomplete is a gift and useful day-to-day, but to make it a central dependency during the development phase seems to be a mistake.
Re: Autocomplete as an Interface (2015)
#100> And the fact that Apple’s methods were designed for autocomplete means that the language is practically unusable in environments without it, which in practice means substantial lock-in to Apple’s proprietary dev tools since no one else invests as much.
This may be true as an effect. But these features in ObjC language (named arguments) and idioms (using them a lot, with verbose symbol names) both date from NextSTEP days, when the developer tool market was entirely different, and I doubt these language features were chosen with any thought whatsoever to this goal.
The author may not be implying otherwise, but some readers may take it that way.
From what I remember of the era, I think the motivations were more about clarity, and maybe some desire to "make code closer to human language." Why make class or method or argument or variable names cryptic abbreviations, when you can just spell them out? Won't this make the code much more readable and comprehensible, and as they knew then as well as now, code will be read many more times than it will be written.
Ruby idioms still lean in the direction of verbosity in symbol naming; perhaps both ruby and ObjC got it from smalltalk, a heavy influence to both. Which is interesting, because smalltalk also famously traditionally locks you into a particular difficult-to-write-an-alternative development environment; but at the time and place the choices were made that led to that, it also surely was not a "commercial" decision.