Luke Champine

I still believe that having the words "map", "filter", and "reduce" in source code is beneficial, in that it lets you reason about your program as a series of data transformations. But providing those transforms via actual generic functions/methods is not ideal.

First, it's impossible to write a single generic implementation that satisfies everyone's needs. In particular, if your "map" function takes an opaque function as an argument, you've immediately ruled out key performance optimizations. No one's gonna use "map" to write memset.

Second, chaining map/filter/zip etc. efficiently requires a sophisticated compiler. And sophisticated compilers suck if you care about performance, because it's difficult to know when and why they will produce efficient code. Systems programmers want DUMB compilers!

So I think treating transforms like normal functions is actually a mistake, at least if you want to get performance-conscious people to adopt them. What I really want is a way to *denote* a block of code as "a map piped into a filter" and have lots of nice tooling around that.

(Macros, I think, are not the right choice here either: it's still difficult to chain them efficiently, and they tempt you to reuse a single generic-but-suboptimal implementation of each transform.)

I guess there's a fundamental trade-off here: if you merely *denote* a block of code as a map transform, you might be mistaken, whereas a map function will definitely be a map function.