Hacker News Reader

Comment by jolux | Hacker News Reader

This is an argument against programming by autocomplete, not an argument against programming with IDEs. IDEs make this method of programming possible, but they don't make it mandatory. The primary thing I use autocomplete for is to insert method calls that I already know that I want. Secondarily I use it like a documentation browser to read the documentation for every function that I could call if I'm trying to figure out a better way to do something. If you program by just selecting functions at random without taking the time to figure out the problem you're solving and the easiest way to solve it with the tools at your disposal, eschewing the IDE will not save you.

I do plenty of programming without autocomplete as well and it doesn't bother me. But it's certainly nice to have, it reduces a lot of the friction of finding documentation and putting code on the page when you already know what you want.

View on HN

Yeah. Autocomplete is about the least useful function of an IDE. The real killer features IMHO are the automatic refactoring tools (method renaming, addition of function arguments, etc) and, in languages that support it, the continuous build that points out errors and warnings as you type them. Code navigation features (go to definition, find every place where this function is called, open file by class name...) are also huge time savers. Autocomplete has its uses but ultimately it's not such a big deal. 99% of the time I use it, I already know what I want to write, and I just use it when I don't remember exactly the order of some function arguments or something like that.

EDIT: I'd like to add that the real speed comes when you have lots of keyboard commands ingrained in your muscle memory. There is a learning curve and it takes some time, but when you're comfortable with mapping certain very high level operations to a combination of 2 or 3 keys, the increase in speed is tremendous. The downside is that changing IDEs becomes a bit painful, so you built some kind of dependence. But this is not what the article is about.

I have ADHD and have terrible memory for names. I'm not even using autocomplete that much, but the navigation in IDE really helps.... or hinders me from learning class/method names.

I have a very wiered and convoluted style of search and navigation, all to avoid remembering names, people who see me coding are really stunded by the way I navigate code.

The upside is I do really well with new languages/projects, unless we are talking millions of lines of code and hundreds of modules, then I begin to struggle again.

autocomplete is a memory multiplier.... it allows developers to be able to use vast/larger array of languages without having to remember every detail of the syntax.

As long as you know the concepts, autocomplete helps fills the details. This is especially useful if you are switching between multiple languages, from Java to Swift to Objective-C in one project. Autocomplete helps you keep productive and makes context switching much easier.

> This is an argument against programming by autocomplete, not an argument against programming with IDEs.

Exactly. IDEs fulfil an important function of removing repetitive and mundane tasks. The goal is to be you, the programmer, to know what you want to do and the tool, IDE, to make it happen as efficiently as possible.

That can happen through parsing code, showing documentation, showing references, alerting to obvious bugs, etc. But it can also be fulfilled by generating code (esp. in environments that like boilerplate) and possibly also by finding pieces of code to achieve the operation you need.

Sure, by using autocomplete constantly I may impair my memory same way that using Google Maps impairs my ability to drive without navigation. So what? I care that the task is completed and my mind is available to thinking about higher level problems rather than how to exactly search the code for references or locate the documentation.

Isn't the goal of software development actually building something rather than obsessing about the process?

There is an arrgument that the details matter a lot in code.

i mostly am familiar with network side of things, but little stuff like how you handle connection timeouts or retries, for example, make a really big difference to the overall quality of the system. Not thinking about a network call each time is setting up a system that will randomly fail in avoidable ways (excessive retries keeping a system from recoverying; excessive buffering in the face of latency; unbounded memory queues causing failure propagatin; having best effort code handle connect failure quickly but not have good rear time outs, etc)

The higher level problems often emerge from the exact nature of the lower levels.

> There is an arrgument that the details matter a lot in code.

The details of resulting code. Not the details of how exactly you wrote it.

Agreed. I don’t think programming with autocomplete is even a problem so much as learning to program with autocomplete is a problem. I think everyone should start out with a barebones text editor to get used to thinking things through and not relying on advanced IDE features as crutches.

I mostly agree. It's a little hard for me to remember how I started because I'm almost fully self-taught and I never restricted myself like that. I think it's best to start people off with a friendly and helpful but minimal environment. Scratch is good for younger kids and is what I started with, and DrRacket is close to ideal for anyone older than maybe 10.

I use Ocaml and the type system and language server basically remove the need for things like a debugger, or even run-time testing while developing, that you might need in some other language. It tells you type of every function, variable, etc. While it's not needed, the language server works in tandem with the type system to basically tell you exactly what's happening in your code.

Type systems are half of the equation, but what do you do when the algorithm is wrong? Type systems don't constrain you from writing incorrect solutions to the echo cancelation problem...you need real world data and runtime tooling for that. This is where IDE type tooling shines, nobody cares about the editor or the code in the end...

I'm currently mentoring someone from scratch and they're using autocompletion a lot. Have mixed feelings about it to be honest. I'm not a big fan of tools like Copilot and it'll be really hard for someone to convince me of its value.

On one side, it's as you mentioned. If you randomly pick a "solution" and hope that it works, you won't understand why you use that specific solution. And sure enough, many times they'd use autocomplete and get a solution that doesn't really solve the problem.

One particular problem I remember was a type difference issue. They had a string and needed to compare it with a string in an object. Easy, just do something like myObj.myVar == "string" right? But autocomplete suggested myObj.equals("string") instead. This is java code. Then I had to explain why it didn't work as intended even though the code compiled.

But observing it more, I decided not to stop them from doing it for now. I think it can be useful for learning purposes especially at the start. It's not that great for understanding but it does help them familiarize with all the different syntax and possibilities.

At the end of the day, I don't think it's that much different from randomly copying solutions from stack overflow until one works.

> One particular problem I remember was a type difference issue. They had a string and needed to compare it with a string in an object. Easy, just do something like myObj.myVar == "string" right? But autocomplete suggested myObj.equals("string") instead. This is java code. Then I had to explain why it didn't work as intended even though the code compiled.

Actually, you need to use `.equals()` for value equality on reference types in Java (like Strings). Using `==` will give you reference equality, which is almost never what you want. You probably wanted `myObj.myVar.equals("string")`

Nitpick! You should always use the constant for the first part of an equality check so you won't get NPE if myobj is null: "string".equals(myobj);

Reply on news.ycombinator.com