Live data from Hacker News

Autocomplete as an Interface (2015)

benkuhn.net

161–170 of 197 posts

Re: Autocomplete as an Interface (2015)

#161
post #156

Earlier quoted context omitted.

When I first started, I spent all of my time writing C at my keyboard with few interruptions. Two decades later, at any given time, I’ll be writing C#, Python, Javascript, yml for CloudFormation, a litany of third party external dependencies, internal libraries written by developers on multiple teams, etc. Not to mention “polyglot persistence” dealing with Mysql, DynamoDB and ElasticSearch. All that and Zi purposeful…

When where you the most productive?

What does that mean ? If you felt better and personally were prouder of the work done back in C with no autocomplete but the business was deriving more value from your work with autocomplete, how should One answer? Or more importantly, what if the requirements are so much more today that if you adopted the same tools as 20 years ago you’d fall behind?

I admire those who stick with their old tools and forgo modern ones so they can stay sharp. They tend to miss the forest for the trees though.

Re: Autocomplete as an Interface (2015)

#162

Earlier quoted context omitted.

> an ecosystem were dependency resolution works My coffee just shot out my mouth.... What? Java --> Diamond dependancies --> Install fickin' maven plugin to print dependency tree --> pray that clashing dependancies converge at some version combination, and that does not cause another issue in a different pair of dependancies (and that I don't have to rewrite my project too much). I really like that nodejs can handle…

I think the real trick is avoiding trickery in the first place. If you got yourself in a weird situation with Maven, either you have a seriously interesting project or you should admit you are probably doing something you shouldn't be doing and should take steps to fix it. Just this week I've been cleaning up some old Java project and as often a major part of it has been to cut down the pom file by 50%. It is now upg…

That’s just simply not true. Diamond dependencies are an all too common occurrence in java if you are writing anything serious. It doesn’t happen everyday but when it does it’s a serious PITA. It’s not a “you’re doing something wrong” but a “someone did something weird somewhere but now it’s up to you to solve”. You just pray it’s someone in your company who was the careless one.

Re: Autocomplete as an Interface (2015)

#163

Earlier quoted context omitted.

> an ecosystem were dependency resolution works My coffee just shot out my mouth.... What? Java --> Diamond dependancies --> Install fickin' maven plugin to print dependency tree --> pray that clashing dependancies converge at some version combination, and that does not cause another issue in a different pair of dependancies (and that I don't have to rewrite my project too much). I really like that nodejs can handle…

I think the real trick is avoiding trickery in the first place. If you got yourself in a weird situation with Maven, either you have a seriously interesting project or you should admit you are probably doing something you shouldn't be doing and should take steps to fix it. Just this week I've been cleaning up some old Java project and as often a major part of it has been to cut down the pom file by 50%. It is now upg…

Or you just have dependencies in your chain which require different versions of guava, or Jackson, or Lombok, or any of the other very common dependencies that still get changes

Re: Autocomplete as an Interface (2015)

#164

Autocomplete, IMO is a crude effort to make text based interfaces more interactive. While it does address some shortcomings of text based interfaces, text based interfaces are inherently flawed to provide enough feedback or context to the user. The only reason we are still using text based interfaces is that the computing system has revolved around UNIX and the command line. The fact that autocomplete is needed for s…

GUI and autocompletion aren't mutually exclusive. In fact I think they compliment each other well. See: your browser's address bar, google's search form, etc. If you're doing anything non-trivial with a GUI, chances are you're using a keyboard of some sort at the same time, and those interactions often benefit from autocompletion.

The reason we're still using keyboards, which are basically late-19th century technology, is because we've yet to figure out a faster and more precise method of getting words out of a human brain and into a machine. You could quibble over qwerty vs dvorak or chorded stenotype keyboards, but all share the premise of speaking using your fingers.

(Voice recognition isn't there yet and probably never will be if human-to-human interactions are anything to go by (it's common for humans to use text to communicate with each other when they need to be precise, even when both share a common spoken language.))

Re: Autocomplete as an Interface (2015)

#165

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…

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…

Sometimes that's because you have to use a different language that doesn't have as much tooling,

Which popular languages these days don’t have a dedicated IDE, plug ins for popular IDE’s and/or support for the language server protocol?

sometimes its because a product gets discontinued, or your employer forces a different IDE, etc.

I wouldn’t work for a company that forced an IDE on me.

In that environment I think learning IDE-specific things makes a lot of sense.

Visual Studio Code works with multiple languages as does Visual Studio.

Re: Autocomplete as an Interface (2015)

#166
post #161
post #156

Earlier quoted context omitted.

When where you the most productive?

What does that mean ? If you felt better and personally were prouder of the work done back in C with no autocomplete but the business was deriving more value from your work with autocomplete, how should One answer? Or more importantly, what if the requirements are so much more today that if you adopted the same tools as 20 years ago you’d fall behind? I admire those who stick with their old tools and forgo modern one…

I wasn’t implying one way or the other and I don’t think that the parent post was either.

The point I was making that when I was writing C day in and day out and mostly just working with a combination of my own code and my companies vote libraries, it was easy to use just a text editor and the command line to build.

But things have gotten more complicated since then. No one could be expected to know the hundreds of functions that make up the entire AWS SDK or all of the options that you need to specify for a typical CloudFormation stack in yml. Of course now it’s even better with the Cloud Developer Kit that lets you generate yml programmatically using a static language - with autocomplete.

Re: Autocomplete as an Interface (2015)

#167
post #35

Earlier quoted context omitted.

I'm a bit confused - isn't autocomplete utterly benign if you don't use it? Using Visual Studio I've never had to autocomplete unless I wanted to, so I've lost no time by having it on if I just want to trudge through, but there's plenty of times I can auto-complete away whole expressions by typing a letter or two and then hitting tab. Regarding nightmarish Java type names I'd rather the name for things be the fully w…

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…

Like, imagine if auto-complete was enabled when writing just regular English. Every time you get half-way through writing a word, a window pops up suggesting that the ending of the word "parli" is probably either "parliament" or "parlimentary". That would be super-annoying, right?

iOS does this and I assume Android does also. In fact, it’s based on what you type frequently. For instance, I use some phrases so often that I get autocomplete suggestions for them as well as company specific acronyms.

Re: Autocomplete as an Interface (2015)

#168

Earlier quoted context omitted.

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…

Sometimes that's because you have to use a different language that doesn't have as much tooling, Which popular languages these days don’t have a dedicated IDE, plug ins for popular IDE’s and/or support for the language server protocol? sometimes its because a product gets discontinued, or your employer forces a different IDE, etc. I wouldn’t work for a company that forced an IDE on me. In that environment I think lea…

> Which popular languages these days don’t have a dedicated IDE, plug ins for popular IDE’s and/or support for the language server protocol?

Most new languages until someone implements it. Again, this is very dependent on what you like to do. If you like trying bleeding edge stuff then you’ll probably run up against this.

> I wouldn’t work for a company that forced an IDE on me.

Sure, sometimes it’s kind of out of their control (or understandable). For example Xcode at Apple. Or if you work in a dev feature that needs to work with some tool or something. Again, my position is that it’s probably fine for most people.

> Visual Studio Code works with multiple languages as does Visual Studio.

OK, it’s interesting you bring up a fairly new entrant as proof this (at least I’m the Mac). Again, my interest is in trying lots of syntax extensions and stuff that usually just breaks these sorts of things. As I mentioned before, if you’re doing application development on a specific set of established languages for a very long time it’s probably the right move.

Re: Autocomplete as an Interface (2015)

#169

Earlier quoted context omitted.

Sometimes that's because you have to use a different language that doesn't have as much tooling, Which popular languages these days don’t have a dedicated IDE, plug ins for popular IDE’s and/or support for the language server protocol? sometimes its because a product gets discontinued, or your employer forces a different IDE, etc. I wouldn’t work for a company that forced an IDE on me. In that environment I think lea…

> Which popular languages these days don’t have a dedicated IDE, plug ins for popular IDE’s and/or support for the language server protocol? Most new languages until someone implements it. Again, this is very dependent on what you like to do. If you like trying bleeding edge stuff then you’ll probably run up against this. > I wouldn’t work for a company that forced an IDE on me. Sure, sometimes it’s kind of out of th…

For example Xcode at Apple. Or if you work in a dev feature that needs to work with some tool or something.

Now you’re giving me flashbacks. I worked for a company where the founder wrote his own VB like IDE/Compiler/VM for Windows CE. I hated every minute of that job until I got the chance to work on the actual compiler written in C++/MFC.

Re: Autocomplete as an Interface (2015)

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

Auto-complete is at least very helpful in two regards: - "Don't make me think". I don't want to wast my brain bandwidth on remembering the details of tens of thousands of the methods/properties/functions, but instead on the logics/architecture/communication of the app I'm building. - Method/property discover-ability, especially for new classes/interfaces/libraries.
Post reply on HN