Erlang-China

为期两天的 ECUG2010 圆满闭幕，按照惯例，交作业。

[ slides videos ]

上次在上海办的，没有去成，这次在北京，无论如何，抛下一大堆事情还是去了。感觉很好，非常之好，但是你又很难跟人讲清楚到底好在哪儿，组织、演讲、提问、茶歇、闲聊……，样样都好，但似乎让人感觉超好的又还不止是这些而已……，具体是什么，我说不上来，还是得大家亲身去感受才行。

这次大家的 Topic 密度都很大，就好像你还没站稳，对方就势大力沉地给你一个降龙十八掌，如果没被砸晕的话，你至少也得腾腾腾地退个十步八步才能站得住。而且，每个人讲的东西都很不好消化，以至于，我这里趁着每日清晨思路最为敏捷之时，勇猛精进地消化了这许多天，也只能大概其地理出一个思路，还得赶紧动笔写下来，以免一会儿又犯糊涂了。

下面开始 Blah …

个人觉得，此次会议 xushiwei 同学关于“不局限于 Erlang 语言”的设想，已经完全实现了，大家的视线已经纷纷“超越了语言”，开始关注更高的目标。然而，很难得的，这样的关注也没有流于泛泛而谈。几乎每个演讲者都在从自己独有的视角，带领大家一起探寻神秘的“程序设计之道”(延伸阅读：[ zh en ])。两天高强度的听下来，让我几乎有了一种错觉——虽然还没有能够亲身体会到“程序设计之道”的深邃，但至少近距离地目击到了在它周围如意流转的五彩祥云。

所谓“程序设计”，就是用写程序的方式让计算机来帮我们解决现实问题。程序设计的“道”，在我看来，就是关于如何漂亮地干好这件事的诀窍。“漂亮”是个很见仁见智的形容词，不仅关乎代码审美，而且也包含了运行高效，简洁流畅，团队和谐……等等，诸多意思，如果不做一下哲学思考恐怕是说不清楚的，而这个思考我还没有做，那么就点到为止吧，反正我的意思你懂的。“程序设计”的目标是“要解决的问题”，而其支点则在于“人+机器”，既然我们这里讨论的核心是“程序设计”，那么对于这个命题，不妨分别从“人”和“机器”两个方面来说事儿。

先从“人”的角度说。曾有智者说过，任何事，归根结底，都是人的问题。不得不说，这真是一句很好用的大废话，屡试不爽。“程序设计”，换而言之，采用什么“技术”(咱们中文的用词还真是虚无飘渺)，毫无疑问，首先要取决于你都有什么“人”。

• 0，因为预算有限，所以要采用“适合于团队”的技术(语言，模型，方案)才能玩得转。
• 1，因为人脑不善于处理复杂的东西，所以要采用尽量简单的技术(理解，表述，模型，方案，实施，接口，惯例)以免犯糊涂。
• 2，因为是人都会犯错，所以要采用“可测试”的技术，“尽早发现”这些不可避免的错误。而且，最好还“可以自动化测试”，这样你就可以让机器来帮你做测试(嵌套到梦的第二层里了吧)。
• 3，因为人的想法总是在变，所以技术要与这些变化隔离(开闭原则，问题域的业务原语)，否则 boss 的想法一变你就完蛋了。
• 4，因为多人协作容易出问题，所以要采用版本管理系统，让机器来帮助你合并每个人的更新(谁来 kick off 一下)。
• ……

说完了“人”，再来说“机器”。对于 CPU 而言，除了“计算”神马都是浮云，计算的输入和输出全部都是“IO”，无论这些数据是在 cache/ram/disk/network 中的哪里，说白了，只是不同速度的 IO 而已。对于现代的计算机而言，计算已经到了多核加速的阶段，相对成熟，而 IO 因为需要处理的数据量仍在急剧膨胀，所以提高其速度仍然还是难题。相对于它的运算能力而言，IO 已经成为系统性能的实际瓶颈。

• 0，你要解决的问题，是 IO 密集型的还是运算密集型的？分布式的网络存储、数据库、Web服务……，不用瞎琢磨，我们常见的大部分应用，对于现代计算机而言，大多都属于前者。
• 1，对于机器而言，唯有计算能力与 IO 能力达到良好的匹配才能发挥出最大的效率。数据离 CPU 越近，效率越高。对现代 CPU 而言，对磁盘 IO 先压缩再读写也已经是一个现实的选择。
• 2，无阻塞 IO，这意味着系统负责 IO 的代码可以一直处于最优运行状态。很多时候，消除系统中的 IO 阻塞比优化算法更为重要。
• 3，在多核系统中，存储的 CPU 亲缘性严重影响性能，运算在多个核之间的迁移意味着大量的低效 IO ，代价很高。
• 4，现代计算机的很多设备标准 OS 的默认设置无法发挥出完全的性能，需要不断调优。
• ……

前面已经提及，程序设计的道，就是用程序设计“漂亮地”让计算机来帮我们解决现实问题。然而，参与其中的人和机器对于“漂亮”的标准却是截然不同的。对“CPU”而言，“漂亮”的方案必然意味着针对硬件的高度优化，具体来说，在现在这个发展阶段，也就是如何实现 IO 与运算的“和谐匹配”，尽量让指令时钟别浪费在“数据的搬运”上。对“人”而言，“漂亮”的方案则意味着简洁与精巧，简洁会涉及各个层面：抽象、接口、代码、实施，精巧则意味着对业务领域的深入的分析与思考。从这个意义上说，我现在所能想到的各种编程套路，“DSL+Compiler”、“BussinessLogic+FrameWork”、“Script+Component”，它们似乎全都分布在以上述两个“美学标准”为坐标轴两端的区间之内。

如何取舍，最终仍然要归结到“人的问题”上。找到一个编译器大拿，不妨华丽地整一套业务 DSL 出来。如果只有几个经验值归零的码工在手，那就还是老老实实地码 Script 就好了。当然了，在管理上，关于质量控制，也就是对“人会犯错误”和“多人协作”的涉及也不可或缺，而且同样重要，只是我们这里不多探讨就是了。

最后，但并非最不重要的是“切蛋糕的技巧”。一个好的切法，亦即所谓的“正交”切分，可以做出“简单”而且“高效”的神奇系统。我们偶尔也见到过这样的系统，比如 Unix 的神奇 Shell ，又比如 Nginx 上的新兴 WebApp 框架(NonBlock IO + UpStream + SubRequest + Computing)。与之相对地，每一个问题都有一千个我们把它叫做陷阱的糟糕切法，每一个都可以让你痛不欲生，靠山山倒，靠人人跑。这样的系统我们每个人都能想起一堆，痛苦的记忆我们已经看了太多，不忍再看。可惜的是，“切蛋糕中的独孤九剑”仍然还只是神技，它的传承，仍然不为我们所知，似乎仍然还是密宗而不是显学。

blah 了很多，累死我了。

上述内容中的很多观点，在这次会议上，多位演讲者都已经谈到，我这里只是“复述+跑题”，被“引用来源”的各位，也没有严谨地一一对号入座，在此一并致谢。

其他
Erlang 的工作机会慢慢多了起来，比如，参会的“唯一”两个老外都提到他们在中国的 office 正在招人。还比如，某同学的庞大 Erlang 游戏开发团队也在迅猛扩充中。还比如我忘了做发布的这个英雄帖：

寻找一些在北京的特别是想换个工作的erlang程序员
联系方式：huangqbbs@yahoo.com.cn

misc