Welcome to the Lounge

F-ES Sitecore wrote:

I'm not an employee, I'm a resource.

Lopatir wrote:

You realise technically that's far worse, both in meaning and implication.

1. Arbitrary iteration (instead of over a collection). "Do this thing X times" is not a map, filter or reduce. Sure you could prepare a list of size X and then map over it, but that's a hack to force it to be done with the M/F/R paradigm, not a trick revealing that all loops are maps. Also if the iterations depend on each other, that's not a map, maybe a fold. "Do this until [cond]" is even less of a M/F/R. I'm sure someone would like to argue at this point that such repetitions are merely parts of M/F/R if you look at a broader picture, but that is far from always true. Consider for example numerical algorithms that iterate until they converge, or simulations of systems that have to be evolved for X time steps.
2. Things that involve a "scatter". That's a lot of things. For example, inverting a permutation - again you can do some dirty hack, but the regular way is iterating result[input[i]] = i for all valid i, which is not like an M/F/R or parts thereof. The "inner" code chooses where to write, so it's not just mapping some function over the array.
3. Almost anything that involves a more complicated data structure such as a heap, tree, disjoint sets, graphs (sometimes. some adjacency matrix algorithms do have an M/F/R structure). It will almost always rely on a specific ordering of side effects, you can't usually just apply operations to the data structure in a different order and get the same (or equivalent) results. Even if the global structure is "sort of like a map", I would argue that the requirement to evaluate strictly in-order makes it not-a-map - proper maps should not have an ordering constraint between evaluations of the function it is applying.