如果你想将函数视为一类对象，Java要求你建立一个有单方法的对象，称为算子对象。许多面向对象语言要你为每个类都建立一个完整文件，像这样开发可真叫快。如果你的编程語言要你使用算子对象来包装方法（而不是把方法本身当成对象），你就不能徹底得到现代（动态）编程语言的好处。不妨试试看你可否退货拿回些钱？
不用再写那些除了经过一个数组对每个元素做一些事情之外一无是处的函数，有什么好处？
让我们看回map函数。当你要对数组内的每个元素做一些事，你很可能不在乎哪个元素先做。无论由第一个元素开始执行，还是是由最后一个元素执行，你的结果都是一样的，对不？如果你手头上有2個CPU，你可以写段代码，使得它们各对一半的元素工作，于是乎map快了两倍。
或者，发挥一下想像力，设想你在全球有千千万万台服务器分布在全世界的若干个数据中心，你有一个真的很大很大的数组，嗯，再发挥一下想像力，设想这个数组记录有整个互联网的内容。还了，现在你可以在几千台服务器上同时执行map，让每台服务器都来解决同一个问题的一小部分。
那么在这个例子里面，编写一段非常快的代码来搜索整个互联网这个问题，其实就和用一个简单的字符串搜索器（算子）作为参数来调用map函数一样简单了。
希望你注意到一个真正有意思的要点，如果你想要把map/reduce模式变成一个对所有人都有用，对所有人都能立刻派上用场的技术，你只需要一个超级天才来写最重要的一部分代码，来让map/reduce可以在一个巨大的并行计算机阵列上运行，然后其他旧的但是一向在单一个循环中运行良好的代码，仍可以保持正确的运行，惟一的差别只是比原来单机运行快了n倍。这意味着它们都一不留神突然变成可以被用来解决一个巨大的问题的代码。
让我再啰嗦一下，通过把“循环”这个概念加以抽象，你可以把用任何你喜欢的方式来实现“循环”过程，包括可以实现让循环迭代速度随着硬件计算能力保持令人满意的同步增长。
你现在应该可以明白不久为何对那些对除了Java之外什么都沒被学过的计算机系学生表示不满了：( http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html) ：
Without understanding functional programming, you can't invent MapReduce, the algorithm that makes Google so massively scalable. The terms Map and Reduce come from Lisp and functional programming. MapReduce is, in retrospect, obvious to anyone who remembers from their 6.001-equivalent programming class that purely functional programs have no side effects and are thus trivially parallelizable. The very fact that Google invented MapReduce, and Microsoft didn't, says something about why Microsoft is still playing catch up trying to get basic search features to work, while Google has moved on to the next problem: building Skynet^H^H^H^H^H^H the world's largest massively parallel supercomputer. I don't think Microsoft completely understands just how far behind they are on that wave.
