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写前端代码，估计是无法迸发出任何火花的。

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

自我认知是循序渐进的，体会到了，就想将其整理出来，给自己一个交代。
                                                                            - Tony Bai

关于我的工作原则，感觉之前的那篇总结的还不够，这两天通过观察自己的所言所行，又有了些思绪，这里记录下来。

* 重塑标准

简单来说就是根据组织实际情况，重新建立各种标准 – 技术标准、人员标准和产品标准。 个人认为这恰是一种实事求是的积极态度。避免陷入技术泥潭中无法自拔，不用Google的人才和做事标准来要求组织内部的人和招聘新人上，认识到存在的差 距。恰如当年钱学森根据国内人力、物力以及实际技术水准重新制定了标准，而不是照搬美国的标准，否则造导弹就会变成一个不可能完成的任务，对团队 士气也将会是一个极大的打击。

* 问题理解要透彻

很多时候，干完了才知道白干了，这往往缘于起初对问题理解的不够透彻，没有抓住焦点，导致Solution不是最合适的，引发不必要的返工。但很 多问题往往无法一次性透彻地理解，这就需要在工作方法上有所调整，以尽可能少的工作消耗去理解和摸索，对工作内容进行阶段性的反思和重构。这样在 1.0, 2.0以及3.0等后续版本的演进过程中，你会发现问题将变得逐渐清晰，焦点也会越来越清楚。而一旦问题被看透，最正确的Solution自然就会在大脑 中形成。

* “眼见为实”还不够

俗语讲：眼见为实。但在工作中，有些时候“眼见为实”还不够，因为很多时候眼中看到的是假象，这在调试和查找技术问题时显得尤为突出。无数次的问 题调查告诉我：始终要保持头脑清醒和逻辑清晰，不能人云亦云，不能轻易相信亲眼所见的“事实”。要追求逻辑的全局合理性，一丝的不 合理都要刨根问底，不遗漏任何蛛丝马迹。

* 把事情做在前面

以推进知识管理为例，在发布知识库之前就应该把发布后可能遇到的各种问题、阻碍想清楚，提前就这些可能的问题给出方法、答案的指导或以Q&A的形 式与知识库一并发布。这些要做在前面的事情包括几类：解放思想的（帮助大家突破原有思维禁锢）、最佳实践的（告知以何种方式去做收到的效果最好）、基本知 识技巧普及的（以大家最易接受的方式对基本知识技巧做出诠释）、服务运维的（还以知识库为例，发布后，你要始终保证其运行稳定可靠，不能让其他人操心于此 事）等。