Simpler in understanding and mental overhead. I want code in my projects being written in a way so that it's maintainable by developers this business can reasonably hire. Which means that they didn't read SICP or even Knuth, don't have experience with functional language and overall are not the x10 developers everybody pretends to have.

I'm old enough to remember when we said the exact same things about OOP, then about Ruby, and now we say them about Elixir, ClojureScript, and so forth.

I very much doubt anybody needs to have SICP at their fingertips, but it seems like many techniques that we deride as being "too far out there" turn out to be quite manageable by all sorts of programmers, it's just a matter of there being enough resources to learn and a little motivation.

This article definitely does not prescribe hurling combinators at every problem, but I will go on record and say that if there's somebody on your team you think cannot understand this code, perhaps you should be a little more optimistic and give them a chance.

Anybody who can figure WebPack, Gulp, Babel, closures, promises, async/await, generators, &c. out can figure this out.

Oh, they can figure it out if they wanted to, definetly. And in about 10 years, they will. That's not my point.

My point is that today, when developers encounter this code while debugging something that needs to be done yesterday, will not spend the time educating themselves and will just ignore it or (even worse) assume they understand it, which is even worse. I don't think that I'm better than them - I just acknowledge my own stupidity. And in my stupidity, in the heat of working on a real project I want to encounter familiar technologies and abstractions that by themselves are almost boring, rather than research new things.

At least when it's out of scope of our technology focus, the core of the project that actually helps it be unique and earn a profit.