Learn at least one new language every year.
                                              — Andy Hunt and Dave Thomas

自己一直是“每年学习一门新语言”的忠实拥趸，曾先后认真地学习了Haskell、Common Lisp、Python、Go等语言，对Prolog、Scala、Erlang、Lua、PHP也有一定了解。但几年下来，只有Python一门语言算 是真正被留在我的大脑里，用在了工作中。其他那几门语言留下来的只是一些思想了。这似乎符合了Andy Hunt和Dave Thomas在《程序员修炼之道》中对于这一实践目的的阐述：“学会用多种方式解决问题，扩展我们的视野，避免思路僵化和停滞不前”^_^。

即便是残存的思想，其实也并不深刻。要真正会运用新思维并非那么简单。一门编程语言从入门到精通，至少要经历学语法、做实践、用idioms（写出地道的代码）三个阶段。这让我深刻的感悟到：不以使用为目的的语言学习，都是在浪费生命！

有精力多学习些语言自然很好，我迫切期待能拥有一个像“七龙珠”中孙悟空那样的“精神时光屋”呢。但现实中，人的精力是有限的，而我们要面对的计算机科学领域中的知识、技能以及问题却似乎是无限的。因此在“每年至少学习一门新语言”这一实践上，建议不要过于教条。 从编程语言自身来看，范型(Paradigm)是影响语言思维差异的主要因素，而编程语言的范型有限，主流的也就那么几种：命令式（过程式）、函数式、逻 辑式、面向对象等。每种范型的背后都有几种、十几种甚至几十种语言，我们其实没有必要都去学。从拓展视野的角度去说，从每种主流范式中找到一两门典型的语 言去学习就可以了。比如命令式的，我们可以选择C；函数式我们选择Haskell；逻辑式的选择Prolog；面向对象的选择Java等。

即便是从每个范型中挑出一门，你要付出的精力依旧不少，我们还要考虑其实用性：要以使用为目的。如果能将其用在工作中，天天与你相伴，被他人接受，自然最 好；退而求其次，你能找到一两个开源项目，并参与其中也是可以的，至少可以让你保持手热；如果这两点都无法做到，仅仅是凭借个人的热情与坚持，那是不会持 久的，若干时间后，你就会对其生疏，可能连基本的"Hello World"语法都记不得了。不过这个年头，思想也不能不要。在有剩余精力的前提下，挑选些牛人们极力“鼓吹”的语言，吸收一下其思想精华，说不定哪天就 能用得上，让自己和大家都感觉你很NB，抬高一下自己的身价^_^。记住：编程语言也是要拼爹的，系出名门的语言(诸如Go、Dart等)自然得到更多的青睐、使用和推广，出位的几率也就高出许多，尤其是在目前新编程语言百花齐放的阶段。因此在选择有思想的新语言时，最好在这些名门之后中做优选。

这个时代喜欢“专家”，因此我们在一两门语言上务必要做到“精专”，这是会给你带来黄油和面包的语言。要专到什么程度呢？我有一个同事，什么问题都用C解决。他甚至为此写了个不小的基础框架，所有业务问题的Code放在框架中被回调即可，即便是这个问题用Python实现只需几行代码。

计算机科学的研究核心是什么？我想肯定不是编程语言，就好比社会科学研究的核心不是人类语言一样。我比较欣赏这样的观点：作为程序员而言，最重要的是去创造，而不是研究。我们应更多的利用已经掌握的语言解决现实中的问题。做 编程语言研究的人可能要了解各种语言的特点与实现方式，但对于大多数的程序员来说，其实我们只需要关注问题域：做底层平台开发的，关注机器模型、通信原理 以及OS原理和实现细节；做算法的，很荣幸，那才是正统的程序设计的核心；前端攻城师则更多关注用户的体验。而在这些解决实际问题的过程中，我们更多采用 的是“制式”的编程语言。即做平台开发的，一般用C，C++等系统编程语言，更多的考虑的是性能；做前端开发的，PHP/JavaScript不可或缺。 我们要考虑的是如何利用这些制式的编程语言去解决问题，而在这些制式语言上，我们要做到精通。

从新兴语言中借鉴新思想，然后在旧语言中实现新语言的特性，其实更多是在旧语言中实现了某 种语法糖，你爱吃，不代表其他人也理解也爱吃，还容易被人误认为是“炫技”。如果你是技术负责人，且经过评估，新语言十分适合这个问题域，那莫不入直接引 入这门语言，让大家都能使用到这门语言的新思想、新特性。

辩证的说，任何一种编程语言都有其利与弊，比如Haskell，纯函数式语言，变量不能改变，无状态，对并行处理具有天然的适应性，但在处理基本IO时却要编写难于理解的monad；而在命令式语言中，这种IO处理简直简单的不得了。

关于函数式语言，个人感觉未来若干年内仍难以大行其道，建议还是跟上命令式语言的演化主线吧。

跨越问题域学习语言，通常收获不大。一个做平台服务端，用惯了C的资深程序员，让他去学PHP写前端代码，估计是无法迸发出任何火花的。

以上是自己这些年关于编程语言学习的一些体会，比较零散，但希望能有帮助。

2002年的Bug A与2008年的Bug B同时穿越到2013年，并在某个场合相遇了。

上周六，项目组本应以一个愉快的心情结束一天的工作的，但一个2002年的Bug A与另外一个2008年的Bug B同时穿越时空来到了2013年，并且恰恰在那时那刻（下班前）相遇了，于是项目组由放松变成了忙碌，由愉快变成了紧张，17：30的下班点也因此延迟到了凌晨1：30。

Bug A来源于2002年我们发布给客户的一版客户端API，严格来说称其为Bug不免有些冤，它只是遇到Bug B时才会被触发，其只是在处理机制上缺少一些容错的考虑罢了。Bug B才是名副其实的Bug，居然明目张胆地违反协议，擅自在登录应答包的Body尾部补了一个字节的“脏数据“，导致使用我们客户端API的某企业短信通知系统出现故障。

关于这次的“故障”，我想感慨的不是这次的Bug有多么的诡异难找，而是下面这几点：

* 生产环境中场景的复杂性与多样性

任你用例再多，测试人员经验再丰富，脑力再强大，也很难设想出如此之情形。往往我们在模拟环境中测试的都很好，开发和测试人员都手拍胸脯保证说：“没问题了”。但一到生产环境中，问题就像滚雪球一样越来越多，弄得大家焦头烂额。究其源头还是在开发人员这里，开发人员是第一责任人。已经离职的制造出这两个Bug的“前辈们“肯定不会想到，他们的Bug居然穿越到2013年相遇了，否则我相信他们在当时一定会认真对待代码的。

* Bug是藏不住的

通过此例可以让我们看到：Bug终有一天是会暴露的，是藏不住的。这“潜伏”了10多年的问题不也在这次事件中暴露出来了吗。所以说我们写代码的时候，一定要心中有“追求0bug”的理想和目标，严格要求自己和自己的代码，采用各种手段，如代码评审、单元测试、持续集成、自动化的模拟环境验收测试等对所写代码进行“残酷”的打磨和考验，让Bug遛到生产环境的机会尽可能地小。

* 版本的变更管理有漏洞

这又是一次在产品升级后导致的“故障”，原因在于没能完整的识别出这次升级带来的所有软件变更。其少引发Bug B的那行代码的“作用”没能识别出来。这的确是个难题，如果不是原开发人员或评审人员“自发”上报此处的变更，这个变更太容易淹没在代码海洋中而丢失了。目前似乎也没有太好的办法。如果未来能有一种自动识别版本间代码不同且能识别出差异代码的语义变更的工具，那么我相信这款工具一定大卖。