3 ms·

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

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.

dgb23 5y ago
That’s what a REPL and automated tests are for.
- layla5alive 5y ago
  Automated tests find all bugs and replace code review? I'd love some of those drugs!
  - dgb23 5y ago
    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.
crazygringo 5y ago
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.
- amildie 5y ago
  >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.
  - crazygringo 5y ago
    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.
jackbrookes 5y ago
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-recursively-list-all-the-files-in-a-directory-in-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).
adkadskhj 5y ago
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.
- layla5alive 5y ago
  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.
kajaktum 5y ago
>most developers can write code a lot faster than they can verify it what? so people just write code and never read it back?
- layla5alive 5y ago
  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-almost-9-years-of-hiding-2d4k https://dev.to/matheusgomes062/a-bug-was-found-in-java-after...

dgb23 5y ago

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

layla5alive 5y ago
Automated tests find all bugs and replace code review? I'd love some of those drugs!
- dgb23 5y ago
  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.

crazygringo 5y ago

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.

amildie 5y ago
>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.
- crazygringo 5y ago
  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.

jackbrookes 5y ago

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-recursively-list-all-the-files-in-a-directory-in-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).

adkadskhj 5y ago

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.

layla5alive 5y ago
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.

kajaktum 5y ago

>most developers can write code a lot faster than they can verify it what? so people just write code and never read it back?

layla5alive 5y ago
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-almost-9-years-of-hiding-2d4k https://dev.to/matheusgomes062/a-bug-was-found-in-java-after...