[delusional]

> I have one guy in our company who wants to unravel any list comprehension or map/generators functions (python) because he doesn't know anything except "for X in Y"

I'm that guy at my current place of work. Incidentally, I'm also always the guy called in to work out why something doesn't work when the guy who made it (and loved streams and CompletionStage) has moved on to a different job.

I can read and write generators and maps just fine (I do it all the time when writing little one off scripts), but debugging in that mess is a hell. When I write something that will outlive my tenure at an organization, I reach for what everyone knows. I write in a dialect that even somebody right out of programming 101 can understand, because god knows what sort of clown they're going to hire after me.

[drekipus]

That doesn't fly in all production environments though.

Sometimes doing 10,000 function calls is a hell of a lot more expensive than sending a 10,000 sized array to one function call.

I'm all for simplifying code, but not to the point of "start at date 0000-00-00 and increment upwards, so what, computers are fast" level (which is close to the type of person I'm taking about)

There's a certain threshold that I would imagine is different for different domains within different companies and perhaps different teams.

I'm fine with people who come out of programming 101 and want to continue to learn new programming ideas, not someone who's going to say my code is wrong because they didn't cover it in their 101 class.

[nvm0n2]

That's partly a Java issue though, due to how streams are implemented. The same code in Kotlin is easy to debug.