I very much have enjoyed our conversations!
As much as I appreciate (and sometimes detest!) JavaScript, I rather doubt that it will ever be used for heavy data analysis.
I can’t tell if you got my last point. Their “historical precedents” are not particularly tied to Google’s Map-Reduce. That is essentially a pattern for distributing fairly simple work on extremely large datasets across large numbers of independent processes. The version of map used in that pattern is very similar to other historical uses of map and to TW’s version. But its reduce is less similar, as it has more sophisticated concerns than most common uses and than TW’s version.
But these should not be thought of primarily as a pair. We have map. We have reduce. We don’t have Map-Reduce, and though we could create one if we chose, I see little reason.
I’m all for improving the documentation. Other discussion here raises the possibility of adding the “SCUBA” example to reduce. If it helps, I’m definitely in favor. As to names, I would not change map, as that is universal. reduce is often called fold, and I prefer fold, but there is no perfect name, and I certainly would not suggest changing it after the fact.
This is what I disagree with. This has very little to do with map and reduce and adding it to their documentation would simply confuse things.
I’m still struggling with the lack of types beyond lists of strings. Although I’m starting to get the hang of it, it still frustrates me. So I would love to have more types, even just key-value objects (I know tiddlers can serve that role…) but I still don’t see this tied to map or reduce.
Think of forEach doing something for every element in a list. Think of map as doing a transformation of every element in the list and returning a new list with those results. Typically, forEach doesn’t return anything, just does something. accumulate would be an equally good name as fold, and probably better than reduce. But I think that ship has sailed.