如果说函数式程序设计语言的复兴还未成为主流的话，那么函数式程序设计的重要特征Lambda函数与闭包已经真正成为主流了。
据图灵出版的《Exceptional C++ Style中文版》作者Herb Sutter的报道，C++标准委员会已经投票通过，将Lambda函数与闭包加入C++0x。同时批准的新特性有：
* N2535 Namespace associations (inline namespace)
* N2540 Inheriting constructors
* N2541 New function declarator syntax
* N2543 STL singly linked lists (forward_list)
* N2544 Unrestricted unions
* N2546 Removal of auto as a storage-class specifier
* N2551 Variadic template versions of std::min, std::max, and std::minmax
* N2554 Scoped allocator model
* N2525 Allocator-specific swap and move behavior
* N2547 Allow lock-free atomic in signal handlers
* N2555 Extended variadic template template parameters
* N2559 Nesting exceptions (aka wrapped exceptions)
加上已经率先拥抱Lambda的C#和其他许多CLR语言（比如VB2008），以及Java 7，还有本就出身“正派”的一堆动态语言……函数式编程的春天已经来了。
当然，对于语言不断增加特性的这种赶集扎堆现象，批评之声也一直不绝于耳。图灵出版的《修改代码的艺术》一书作者Michael Feathers就发出疑问了：“Will Java 7 Be Beautiful?” 一种新的特性，有其利，也必然有其弊。而且各种语言本来就各有擅长，何必勉强地改得越来越像？从另一角度来说，混合使用多语言，在虚拟机一层为多语言的集成更多地努力，也许是更正确的做法？

转自 http://blog.csdn.net/turingbook/archive/2008/03/30/2231691.aspx

D新闻组里报道的时候就看过了，C++ 的新'入'语法真丑

很赞同上面的观点，在OO类语言中加入 Lambda函数／闭包简直变成了四不像。

为迎接多核现在各个都加 Lambda函数／闭包，

都没人考虑通过不可变对象加上传统线程模型的方式，

我最近就在构思怎样在OO类语言中把 Lambda函数／闭包赶下台。

Lambda/Closure和多核没什么关系吧，它只是方便FP，还有就是很容易根据当前上下文构造处理逻辑。

我觉得语言里加任何东西都没什么关系，这些你可以不用，只要不影响旧的用法。

RUBY的block就是闭包closuer可以构造continuation

请看:
http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-February/000047.html

里面有一段话：
The Clear Need
==============

A discussion of the needs satisfied by this proposal appears in a
draft JSR proposal at http://www.javac.info/consensus-closures-jsr.html.
In summary, the draft specification supports the development and use
of APIs that significantly improve the use of concurrency for
multicore systems, and enables the development of APIs that
significantly reduce boilerplate for some common programming patterns.

Lambda/Closure这种东西你可以认为它是一个黑箱，
只要黑箱里不涉及I/O调用，外部想跟它发生关系，只能通过入口提供参数给它，
然后它返回一个结果给你，它不像Java中的对象，一个对象它可能包涵了很多字段，
还提供了很多公用方法来操作这些字段，在多线程的场合你就得小心的进行同步，
防止对象字段的值不一致。

也就是说对象是有状态的，对象里头的字段记录了每次的操作结果，
而Lambda/Closure实际上就是一个函数(不管是一阶还是高阶)，
它仅仅相当于一个对象中提供的某一个公用方法，它没有字段，
你可以认为它是没有状态的，有多个线程要来执行这个函数，仅仅是执行这个函数中的指令代码而已，执行完了就得到一个结果，多个线程之间不需要同步或互斥来保证任何的数据是否一致，这样就省掉了与对象锁有关的任何开销。

Erlang之所以支持那么高的并发量，除了它是基于消息传递的进程通信模式外，
最主要还是要归功于它的进程之间是没有数据共享的，
而要做到无数据共享最后又可归结到Lambda/Closure。

我现在想，要是用不可变对象来模拟Lambda/Closure的形为，
然后在VM的层次调整一下传统的线程调度模型，这样也许也是一条可形的路子，
在Java，C＋＋中加入Lambda/Closure只会让写出的代码越来越缺乏美感。

这个是基于一些纯函数式语言的结论吧，在OO里面应该没办法禁止在Lambda/Closure里面多个线程修改同一对象。。


C++里面少点美感也无所谓了，能少写点代码还是很值。

是的，我前面已说了不涉及I/O之类的外部调用啦，指的就是纯函数的情况。

OO里面有没有办法禁止在Lambda/Closure里面多个线程修改同一对象，现在不确定，
Java的Closure也是个草案，不代表以后的正式规范。

在Java的Closure草案中
http://www.javac.info/closures-v05.html

有这样一段话:
it is a compile-time error if the function being converted refers to a non-final local variable declared in an enclosing scope.


貌似在编译期间就不准在Lambda/Closure里涉及non-final变量，
换句话说只能是final变量，也就是不可变的。

这跟我上面提的“不可变对象”其实思路都差不多。