4 ms·

This begs the question: What best practices can significantly reduce blunders and are (more or less) portable across languages? In my opinion, a good start is

This begs the question: What best practices can significantly reduce blunders and are (more or less) portable across languages? In my opinion, a good start is learning to use filter/map/reduce instead of big nasty for loops.

legulere 8y ago
Fail fast, avoid mutability, write tests
- AstralStorm 8y ago
  Fail fast in development. Have fallback code for deployment or you will be in deep trouble. And as all solutions, sometimes the cost is too much for the immutability. Writing tests is a bit glib...
AnimalMuppet 8y ago
Big nasty for loops get replaced by big nasty filter/map/reduce calls. Filter/map/reduce may be less error prone than for loops, but if it would be a big and nasty for loop, it will still be big and nasty. Worse, "nasty" to me means more than just "what was inside the loop is large". It means that the loop itself was nasty, that is, it wasn't just a straightforward iteration over a collection, or a loop with fixed bounds. That means that it's harder to just replace it with a filter/map/reduce. I think that for loops can be hard for beginning to intermediate programmers, but with experience, they get easier. I don't remember exactly how many times I've messed up a for loop in the last decade, but the number is either 0 or 1. It's not 2. "Once in a decade" isn't exactly the source of large-scale bugs that people often claim for loops are. Note well, though: This is not my first decade as a programmer. The number was much higher my first decade. Filter/map/reduce may be easier to learn. You may in fact get to "one bug per decade" faster with them.
- mseebach 8y ago
  You seem to be comparing a well-written, large for-loop (that has complexities dictated by true constraints, rather than programmer skill) with a poorly written functional chain. This isn't quite fair. The functional style nudges the programmer to think in the smallest semantic steps of transformation, in a way that the for-loop doesn't. Of course the programmer can ignore the nugde and write the same messy for-loop using functional constructs, and a good programmer can equally well write a big for-loop in a very manageable and easy to read style. But for an unexperienced programmer seeking general advice, I feel that recommending the functional style (with an additional urge to "listen" to what the style is trying to get you to do) is a pretty safe bet.

legulere 8y ago

Fail fast, avoid mutability, write tests

AstralStorm 8y ago
Fail fast in development. Have fallback code for deployment or you will be in deep trouble. And as all solutions, sometimes the cost is too much for the immutability. Writing tests is a bit glib...

AnimalMuppet 8y ago

Big nasty for loops get replaced by big nasty filter/map/reduce calls. Filter/map/reduce may be less error prone than for loops, but if it would be a big and nasty for loop, it will still be big and nasty. Worse, "nasty" to me means more than just "what was inside the loop is large". It means that the loop itself was nasty, that is, it wasn't just a straightforward iteration over a collection, or a loop with fixed bounds. That means that it's harder to just replace it with a filter/map/reduce. I think that for loops can be hard for beginning to intermediate programmers, but with experience, they get easier. I don't remember exactly how many times I've messed up a for loop in the last decade, but the number is either 0 or 1. It's not 2. "Once in a decade" isn't exactly the source of large-scale bugs that people often claim for loops are. Note well, though: This is not my first decade as a programmer. The number was much higher my first decade. Filter/map/reduce may be easier to learn. You may in fact get to "one bug per decade" faster with them.

mseebach 8y ago
You seem to be comparing a well-written, large for-loop (that has complexities dictated by true constraints, rather than programmer skill) with a poorly written functional chain. This isn't quite fair. The functional style nudges the programmer to think in the smallest semantic steps of transformation, in a way that the for-loop doesn't. Of course the programmer can ignore the nugde and write the same messy for-loop using functional constructs, and a good programmer can equally well write a big for-loop in a very manageable and easy to read style. But for an unexperienced programmer seeking general advice, I feel that recommending the functional style (with an additional urge to "listen" to what the style is trying to get you to do) is a pretty safe bet.