对于很多已经成为资深的开发人员而言，C# 3.0及其Lambda + LINQ的出现就好像晴朗的天空中从远处飘来的一片乌云。原因是，当我们致力于研究如何应付业务快速变化的同时，语言本身的灵活性却在空前提高，不断的变革。如果您对COM开发中的各种宏和Inline定义还记忆犹新的话，相信您也不会忘记那个时代看起来很“Cool”的与很平凡的代码之间的区别；现在C# 3.0又把这些翻出来，只不过这次变革的动力更多来自于如何在访问数据时动态提取强类型的需求。很多以往我们需要数十行代码完成的函数现在只要一行Lambda表达式就可以了，而且因为它执行的对象可以根据需要切换到不同的数据源，如：XML数据、关系数据库，甚至Google和Amazon的Web服务。因此，是否掌握语法中这些新的特性将很大程度上关乎你团队的开发效率，起码是编码部分的效率，难点在于是否还有心思坐下来重新学习这个“熟悉的陌生人”了。比如：下面一段代码仅仅是对一个一维数组操作的对照测试组：
public class Test { int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 }; public IEnumerable TestLambda() { return numbers.TakeWhile((n, index) => n >= index); } public IEnumerable TestOrdinaryRoute() { IList list = new List(); for (int i = 0; i < numbers.Length; i++) { if (numbers[i] >= i) list.Add(numbers[i]); else break; } return list; } }


当模式和迭代成为我们这个时代开发主旋律的时候，动态语言因为其灵活性快速膨胀至Web开发的方方面面，但动态语言是否有足够的力量的开发我们需要的ERP、CRM等OLTP应用呢？应该可以，不过我不太会用。对于很多用户而言，“能够早点完成工作按时下班就是最好的用户体验”。而Lambda只是一个开始，他刚好位于一个全能的通用语言之中，并令C#本身在可以支持密集计算的同时，又可以根据外部类型的变化、根据外部信息对象的变化，主动地调整自己的计算；并且可以把这些动态变化的能力从业务对象一直传递到最前端的用户界面部分。上面的例子只是对一维数据的操作，但随着业务规则日趋复杂，我们经常面对的是，用关系数据库或XML数据库组织的具有层次关系的数据（比如：用户提单和提单明细间的关系）；这时候在操作相对复杂结构对象的时候，Lambda的简洁优势更加明显了。


当语言的灵活与语法的复杂汇合在一起的时候，我们也许很有必要重新认识哪些是最容易的，哪些需要投入更多时间来琢磨的。语言未必是最容易学习的部分。

本文来自于InfoQ 王翔译