for(blah blah blah)
map(blah blah blah)
All programming techniques should be viewed as means to write code that's some combination of readable, reliable and performant, not as ends themselves.
Except in this case it wasn't actually a sequence, but an Optional/Either and it wasn't about transforming that sequence but about error handling. So in a way the code wasn't even not intention-revealing, it was actually deceptive.
However, just as I also wrote, that's not an actual sequence of values, it's a single wrapped value (or none).
Optional can generally be thought of as a "sequence" of one or zero values. You could use an array of "[some]" or "[] /* none */" to manage control flow in an almost identical way (you'd just be adopting and managing an API that doesn't statically ensure that these arrays never have more than 1 value).
"map/flatMap" are predictable functions that can be used to manage the transformation of data (which is generally the entire point of code). The type/context that a computation is lifted into communicates a lot: Optional, for example, can be returned for a computation that may or may not return a value, and it can be "mapped" into another value by a pure computation that _always_ returns a value, or "flat-mapped" through a computation that may produce another nullable value. Anyone familiar with these basic functions can jump in, read the code, and generally know that every computation lifted into "map" can't fail, while every computation that is "flat-mapped" can. And in static languages it's all checked by the type system! No testing for "null" everywhere!
I don't use partial application/currying that much, but more and more over time.
All in all I feel that doing these things have greatly improved my code and efficiency, and I'm kind of waiting for some downtime to get back into learning the more 'hardcore' functional languages.
It might be said that any such example would be too complex and drawn-out for an article like this, but if so, then to me that is like the drunk looking for his keys under the lamp-post: writing an article that claims a simple example shows a profound difference, when it does not, suggests that the Emperor's wardrobe is threadbare. The thing to do is to provide links to articles where this is worked out in sufficient depth, and I would like to see some of those links here.
* Mapping (producing a data structure of the same size/type)
* Filtering (producing a data structure of the same type buy smaller)
* Side effects
* Collecting (producing a different data structure)
If you're incredibly unlucky or foolish a for loop might be doing more than one operation at a time!
Assuming you're only using the return types, map, filter, and collect are very clear about having only one purpose.
If that's not telling you more I don't know what is.