Hacker News Reader

Comment by crazygringo | Hacker News Reader

> If you need to go through the suggested code to ensure it's correct, you may as well write it yourself?

Not really. People are generally far faster at reading something and evaluating whether it's correct, than at writing something. In the same way it's faster to read a book than to write one.

Not to mention the time it takes typing, fixing typos, etc.

So this could genuinely be a huge timesaver if it helpful enough of the time.

View on HN

I completely disagree with you. Reading code for correctness is difficult and not something most people do well at all. Reading code and reading for correctness are not the same, and most developers can write code a lot faster than they can verify it.

I'd say it's more nuanced. Reading code properly _is_ writing code. Ie i have to work through the logic as if i'm writing it, which is effectively writing it in my head, before i know if that's what i believe to be optimal.

I can _just_ read the code of course, and understand what it does - but just reading isn't analyzing it to the degree you do when you review/write the code. In that level of analysis you're looking for edge cases, bugs, etc. Reasons you'd write it differently. Which i suspect is functionally similar, if not identical, to writing it.

It's pretty much this, but it's harder because if someone else wrote it, there's a level of indirection between how you would have written it and how they did which tends to need a bit of extra mental resolving/processing for correctness.

I guess we just disagree?

Honestly I don't even see how that's possible. Writing code, you're thinking about all the different ways to do it, eliminating the ones that won't work, evaluating the pros and cons of the ones that seem like they'll work, you start writing one and then realize it actually won't work, then start writing it a different way, try to decide what the best approach will be to make sure you're not committing an off-by-one error, and so on...

Whereas when you're reading code for correctness, you're just following the logic that's already there. If it works, it works. How could it possibly take longer than the whole creative process of coming up with it...?

Sure, maybe most people don't read code for correctness well. But then the code they write is surely even worse.

>Whereas when you're reading code for correctness, you're just following the logic that's already there. If it works, it works. How could it possibly take longer than the whole creative process of coming up with it...?

That's exactly the problem. If you "just follow the logic" you can miss important details or edge cases that you would be forced to deal with by coding it yourself.

I wouldn't mind using something like this for mundane tasks, but I would be very careful with these tools while developing high performance code intended to run on specific hardware.

It's funny, I guess I'm just the opposite.

If I'm reading code, I can give 100% of my attention to the logic and details and edge cases, so I'm more likely to pick them up.

While as I'm writing, I'm busy doing all of the stuff that writing code involves, so I'm more distracted and more likely to make mistakes.

This gets proved to me time and time again when I run something for the first time and have to debug it. I look at the offending line, and think -- how could I have made a mistake so obvious that it's immediately apparent? Well, because I was busy/distracted thinking of 20 different things while writing it. But it's immediately obvious when reading it, because it has my full attention now.

>most developers can write code a lot faster than they can verify it

what? so people just write code and never read it back?

Verifying code and reading it aren't the same thing. And yes, most developers don't verify their code as carefully as they should. But also, there are blind spots to verifying your own code because brains take shortcuts. At the same time, there are difficulties verifying other people's code because of different shortcuts brains take.

There was a simple function in java standard library which was wrong for years because of this phenomenon.

https://dev.to/matheusgomes062/a-bug-was-found-in-java-after...

Sometimes you don't quite know how to implement something, without thinking about it for a while. All of us would a lot of the time search StackOverflow for the solution to a simple problem, e.g.

"recursively list all the files in a directory C#"

https://stackoverflow.com/questions/929276/how-to-recursivel...

I imagine an AI copilot could streamline this, instead of searching, reading and verifying, copy pasting, and changing the variable names to my needs, I could now just type the method name, arguments, and documentation and it would similarly fill out the code for me. Then I have to check it (as I normally would).

That’s what a REPL and automated tests are for.

Automated tests find all bugs and replace code review? I'd love some of those drugs!

No, of course not. I meant understanding what you write, while you write it. Also to add a bit of nuance: I typically spend much more time reading and thinking rather than writing. But I read REPL output, logs, test output just as much, sometimes more than the actual code.

I’m going to pile on the disagree train. My experience is that developers find (other people’s) code much harder to read. I suspect this tool will lead to code with subtle problems because people will skim it, shrug “eh, looks about right,” and move on.

Edit: In fact, people in this thread are finding exactly those problems in the example code, which you would assume had been checked fairly carefully.

idk I always find writing code easier than reading code. Perl is a fantastic example of this.

Reply on news.ycombinator.com