3 ms·

> The second version is much clearer to me Clearer? Did you notice the second version contains a bug? The first version makes it easier to spot said bug, beca

by the_af 5y ago

> The second version is much clearer to me Clearer? Did you notice the second version contains a bug? The first version makes it easier to spot said bug, because it's more concise and with fewer parts where you could make a mistake. Note that even in this very short piece of code it's easy to miss the bug; imagine in actual loops! You have no guarantees about the running time of the code in either case, not without delving into the specifics of your programming language. > I favor a programming style where all loops have clearly identifiable bounds. Using "iterators" hides these lenghts and makes the code much harder to reason about. I find the opposite to be the case. Explicit loops with indexes make off-by-one errors likely, which is one of the most common kinds of error. It's impossible to make that kind of mistake with a foreach or map-over-this operation.

maest 5y ago
> Did you notice the second version contains a bug? Whoops - in my defence, I haven't coded in C in a very long time. I'll leave it there, since I think it makes an (unwittingly) good point.
enriquto 5y ago
This is mostly a matter of perspective. An off by one error may go harmlessly unnoticed at worst, or trigger a harmless segmentation fault at best, in which case it's very easy to find and fix the silly problem. On the other hand, code that hides things tends to be much harder to debug, when it invariably fails. Why is my program suddenly gobbling 10GB of memory? After several hours of profiling and debugging: ah, here's this particular combination of constructors that allocates and frees a stupid amount of memory for no reason.
- the_af 5y ago
  > An off by one error may go harmlessly unnoticed at worst, or trigger a harmless segmentation fault at best, in which case it's very easy to find and fix the silly problem Yes, but even better if you don't write the bug to begin with. It can also fail harmfully, like failing to trigger a segfault but producing the wrong computation, resulting in sending the wrong amount of energy to the X-Ray machine, the wrong amount of money in a bank operation, firing the wrong number of missiles, etc. > code that hides things tends to be much harder to debug, when it invariably fails In the general case, I agree. In the case of foreach loops (or maps or folds) the good thing is that they are well understood abstractions, not something your fellow coworker wrote and that you must understand from scratch. They are common idioms, just like you don't debug (under normal conditions) how a for-loop with an index works internally.
- RHSeeger 5y ago
  > An off by one error may go harmlessly unnoticed at worst, or trigger a harmless segmentation fault at best Or be used in a remote code execution attack. So "harmless unnoticed" is FAR from the "worst" case.
  - yjftsjthsd-h 5y ago
    Yeah, I had to reread that because I'm pretty sure "silently wrong" is the worst case, and not harmlessly so; I would 100% prefer segfaults, which let me actually fix the problem or at least know something's wrong.

by the_af 5y ago

maest 5y ago

> Did you notice the second version contains a bug? Whoops - in my defence, I haven't coded in C in a very long time. I'll leave it there, since I think it makes an (unwittingly) good point.

enriquto 5y ago

This is mostly a matter of perspective. An off by one error may go harmlessly unnoticed at worst, or trigger a harmless segmentation fault at best, in which case it's very easy to find and fix the silly problem. On the other hand, code that hides things tends to be much harder to debug, when it invariably fails. Why is my program suddenly gobbling 10GB of memory? After several hours of profiling and debugging: ah, here's this particular combination of constructors that allocates and frees a stupid amount of memory for no reason.

the_af 5y ago
> An off by one error may go harmlessly unnoticed at worst, or trigger a harmless segmentation fault at best, in which case it's very easy to find and fix the silly problem Yes, but even better if you don't write the bug to begin with. It can also fail harmfully, like failing to trigger a segfault but producing the wrong computation, resulting in sending the wrong amount of energy to the X-Ray machine, the wrong amount of money in a bank operation, firing the wrong number of missiles, etc. > code that hides things tends to be much harder to debug, when it invariably fails In the general case, I agree. In the case of foreach loops (or maps or folds) the good thing is that they are well understood abstractions, not something your fellow coworker wrote and that you must understand from scratch. They are common idioms, just like you don't debug (under normal conditions) how a for-loop with an index works internally.
RHSeeger 5y ago
> An off by one error may go harmlessly unnoticed at worst, or trigger a harmless segmentation fault at best Or be used in a remote code execution attack. So "harmless unnoticed" is FAR from the "worst" case.
- yjftsjthsd-h 5y ago
  Yeah, I had to reread that because I'm pretty sure "silently wrong" is the worst case, and not harmlessly so; I would 100% prefer segfaults, which let me actually fix the problem or at least know something's wrong.