1、应用VS.语言
应用是特性越多越好，应用是rich的；而语言是pure的，更少的、普通的特性更好。
2、添加一个java语言特性的三个前提：尊重过去、着眼未来以及顾及模型。
无论是增加、减少或者改变一个feature都可能broken已经存在的代码，一个新增加的feature必须兼容已经存在的代码，兼容是个沉重的包袱，就java语言而言，我相当认同尊重过去这一点，哪怕加入闭包这样的特性也不应当以损坏兼容性为代价，更好的选择是将这些特性让jvm上的新语言去实现（比如JRuby、Scala），java语言作为成熟的工业语言本身不应当做太大的改变。而着眼未来，也就是说新的语言特性应该为未来的语法扩展留有空间，它的语法/语义不应当跟现存的或者潜在的特性相冲突，以便可以持续地演化。再谈顾及当前的模型，一门语言代表着一种计算模型，比如simula是OO模型（classes)，Erlang就是inter-process communication的模型(actor）。Java语言也有一个简单的模型：首先它是“高层”语言，是一门通用、并发、基于类的OO语言，其次，它跟API、JVM有良好的结合。Java语言模型有四个原则：
a)鼓励high-level实践，通过抽象来隐藏偶然复杂度。简而言之：do the right thing。
b)追求清晰，程序被读的时候远远多于写。简而言之：do the thing right.
c)青睐静态类型，静态类型能增进对代码的信心，静态类型能证明bug在编译时的不存在，而测试和动态类型能证明bug的存在。我的观点是，大多数难以寻找和解决的bug都是runtime的，静态类型在此方面能给出的帮助有限，充分并且适宜的测试更加能增强你对应用的信心。
d)语言比之API的更广泛。one language,many api。API来去匆匆，而语言却是forever，因而将语言和API分离是明智的，一些特性可以做为库来实现，jdk5并发库的引入就很好，jdk7在并发方面同样将引入fork/join模型。
java语言的演化也当遵循这四个原则。再看看传说中的闭包语言，当它跟泛型结合的时候写出来的东西还谈得上清晰吗？闭包的实现能否解决兼容性问题也是个疑问。就四个提案，C3S需要引入method关键字（类似lambda)，FCM的#号看起来比较怪异，在我看来，CICE和BGGA更符合胃口，CICE对java语言的变动应该最小，学习曲线也比较平缓，BGGA的=>符号更有函数式语言的味道。闭包的引入，某种程度上能减少敲击键盘的次数并实现一些高阶功能，特别是在聚合操作（如filter、map等）和单抽象方法类（如Runnable,Callable）的使用上，但是在现代IDE的自动化帮助下，这个带来的价值是值的怀疑的。
文章转自庄周梦蝶 ，原文发布时间2008-06-18
