> Solve your problem.
When I worked on a complex framework in a small team, we used Objective-C. In the early days of the project, we created some powerful utility methods like map and reduce which we used extensively in the early stages. These methods let us do things like traverse complex structures very compactly. Way better than the more plodding while-loop (perhaps with a stack) way of doing it. But, I found myself moving away from these later in the project in favour of more verbose code because it took me too long to understand the map/reduce code if I needed to revisit it. The longer code was, um, longer, but it was much easier to understand what I (or my colleagues) had done when I came back to this code. In my view, a bunch of very smart programmers can indeed be "hyperproductive" using a language like Smalltalk, but this hyper-productivity may not survive the longer term life of the project.
The very same thing happened when structural programming was invented, and Fortran-iV guys were saying that all these "while" and "until" loops are harder to read than computed gotos.
Very long streams can be combined of shorter stages, and these stages are individually testable, when needed.
I discovered list comprehension and was exited and used them a lot. Then I went to multi level list comp. Then I realise I could never debug those so went back to loops for anything needing more than a single level. Finally I discovered Generator Expression which are basically like list comp, but lazy (not evaluated) and since then I break my code in a series of generator expression which I materialise at the end with a single list comprehension. This way I keep my code readable, it's a lot cleaner then a bunch of loops, and I also benefit of Python's special optimisation for list comprehension.
Arguably it's even easier because you you generally know you won't have inter-item dependencies.
But yeah, map/reduce are so common nowadays that I think most people would not have a problem with them anymore. Even Java is doing them now :)
OTOH, if you've never encountered them because you come from languages that did not have them, they might be confusing at first. Some of my colleagues did have trouble getting used to map/reduce when Java8 came around.
This may be part of the problem with hyper-productive languages in general, you get stuff done fast but it tends not to be documented as well as a publicly available programming language.
map() that is part of the language is also very STABLE whereas if you write your own you are likely to tinker with what it does here and there, what default argument-values it uses and so on.
A regular function call is first-order:
foo(bar: Int): Int
while(keepGoing: () => Boolean, action: () => Unit): Unit
while[M: Monad](keepGoing: Monad[Boolean], action: Monad[Unit]): Monad[Unit]