A plain old for loop has so much to recommend it. You get powerful control flow constructs (break/continue/return) and obvious performance characteristics.
Can you tweak your function to stop filling the first time a zero is encountered? That's a simple one-line change with the for loop, but a puzzle for the functional iteration.
Option and Result are tolerable without language extensions (as long as your language has first-class functions and parameterized types, which you want anyway) - https://fsharpforfunandprofit.com/posts/recipe-part2/ . do notation is a small, purely-syntactic piece of sugar that's usable for many different cases, not just error handling.
> A plain old for loop has so much to recommend it. You get powerful control flow constructs (break/continue/return) and obvious performance characteristics.
Those are all language extensions! You're talking about adding four keywords to the language, none of which are anywhere near as reusable as do notation.
> Can you tweak your function to stop filling the first time a zero is encountered? That's a simple one-line change with the for loop, but a puzzle for the functional iteration.
Different code should look different. map, reduce, fold, traverse, foldM are all different functions that do different things, but they're easy to work with because they're all normal functions that obey the rules of functions (and if you're ever confused you can just click through to the implementation in plain old code). Languages don't want to offer several different variants of "for" because it's a language keyword that has to be supported at the language level, but the result is that the "for" loop is far from simple - it does several different things depending on how exactly it's used, and you can't tell which except by going through the details every time.
I think we disagree on what "different code" ought to mean. I have a C function which multiplies a list of numbers; I make it immediately `return 0` if it hits zero. In C that's the same function, just optimized; in Haskell it's a breaking API change due to laziness. I suppose the languages reflect that difference.
Obviously in the trivial case though a loop is very easy to understand. The trivial case usually, in my experience, involves iterating through the entirety of an array though anyway, in which case the map is usually more concise.
YMMV! :)
I like your strength/weakness observation. But if you are mutating index variables, you have a hard case, and it probably will be easier to express with a manual loop than trying to shoehorn it into awkward functional constructs.
An example is the "discard elements by a predicate" function, aka Vec::retain in Rust, std::remove in C++. Rust implements this using a for loop. Maybe it can be done with functional constructs, but it would be harder to write and to understand.
for (ElemType x : collection) {
# use x here
}
for (elem : collection) {
// use here
}
Not sure what you can do with this that:
collections.each(x -> {
// use here
})
Either way, like most things in functional programming, it's often about restricting your functions so that they're easier to reason about. There's nothing special about the map function really in any pragmatic sense except when used in conjunction with the other features a good language affords.
I'm also curious if you think something like:
listOfListsmap : List (List Int) -> List (List Int)
listOfListsmap =
(List.map << List.map) (\n -> n + 1)
collections.forEach(x -> {
// anything could happen here to x before the inner loop processes it
// and since we're probably dealing with mutable variables, the inner loop can
presumably access things I put here (which may or may not be a problem, but is something you have to think about)
x.forEach(y -> {
// do something with y, we can do anything with x *and* y here
y = y + 1;
}
}
Yes, and that's exactly why you should use constructs like map when possible. With a manual loop you have to scan more code to verify that it's not doing something more complicated.
In Rust:
a.iter_mut().take_while(|i| *i == 0).for_each(|i| *i = 0)
A plain old functor/monad has so much to recommend it. You get a uniform way to iterate/transform all kinds of collections, even those which don't support indexing. They can also be used without mutation and are easy to typecheck. In languages with higher-kinded types they can be abstracted over without knowing anything about how the underlying data is structured.
I spent 3.5 hours with a junior team member yesterday refactoring break and continue out of her loops. The code was so much more readable afterwards.