4 ms·
It's subjective. My experience is exactly the opposite. A pipeline of sequence operations is something I can skim at a glance, but a for-loop is a pile of code
by lmkg 7y ago
It's subjective. My experience is exactly the opposite. A pipeline of sequence operations is something I can skim at a glance, but a for-loop is a pile of code that I need to stare at before I understand what it represents.
This does not invalidate your experience. It's common, and with good reason. This sort of dissimilar experience with the same code is why coding standards need to be views as social norms for the team using them, and not just technical things.
- eru 7y agoThe problem with loops is that they are too powerful. They can do almost anything. The functions map and filter are nice and restricted. If you want more power, you use eg a fold. And if you need even more power, you write a new recursive function. So a quick look at the code will tell you what to expect.
- edflsafoiewq 7y agoPersonally I've found that although this argument sounds good in theory, in practice I don't find loops harder to read than chains of combinators.
- eru 7y agoWhich languages are you reading them in? For me the argument holds in practice as well. I'm mostly reading my combinators in Haskell, and the loops in Python or some curly brace language. If you use a general purpose combinator like mapAccumL that has almost as much power as a loop, you don't get that much extra readability compared to the loop. It's still a bit better, because that combinator still has to process one element of your list for each run through it's "body"; and it clearly warns you by it's very name that it's not just a filter or map, so there's less possibility of confusing it for something simpler. And, of course, not all loops are created equal. When applicable, for-each loops are much cleaner than classic C-style for-loops for example.