Maps are explicit transformations of data. For some, making the business logic explicit is simpler.

Loops are just implicit goto...

The argument for maps and folds is the same as the argument for structured programming in general: using common/reusable idioms brings clarity and familiarity.

Terseness doesn't necessarily bring clarity.

It's the recognizability, not the terseness, that brings clarity.

Although Python's approach is not terse -- `fstyle = [f(x) for x in arr]` -- it is eminently recognizable.

Your argument is not really about anything I specifically said; and without something to counterbalance, it argues against structured programming, too.

How does it argue against structured programming?

My argument is that "recognizability" is in the eye of the beholder. One programmer's "map is a powerful abstraction over transforms, for example loops" is another's "this is some cutesy code/math creole by a CS graduate who desperately wants to find nails to apply his functional programming and applied math hammer on".

That's a fairly harsh way of saying that at some point the abstraction isn't clarifying, whether it's recognizable or not.

Disclaimer: I'm a big fan of functional idioms (they're one of my favorite parts of Rust, for example). I'm not so much a big fan of absolutism or over-generalization.

No, maps are conversions between types containing other types. Maps are much more powerful than just doing something over an array in languages that support a functional style.

The original comment was comparing maps and folds to loops, not the general application of maps.