几个月前，一个同事问我，应该如何选择编程语言，或者有没有什么固定的选择模式，当时我便打算写点什么。上周在硅谷开会，这我是第一次跟 “hack3rs”的创业狂以及技术狂们打交道。我学会了很多前所未闻的脏话，也有所得–即便是追求精简的初创企业也倾向于把问题过份复杂化。
将真正领悟精简精神的人甄别出来并不困难。谷歌，Facebook以及Akamai的程师们的讲座魅力十足。他们从一个更宏观的角度思考和解决问题。这跟公司的财力，规模没有关系，他们特意剪除细枝末节，以便将注意力集中在问题的根本。 我自己也曾一味要求手下考虑使用高级编程语言甚至全面向对象语言，我发现许多的新时代初创企业也还没领悟其精髓。他们用Javascript、Python和Ruby编程，却不明白为什么要用这些语言。 不可否认，把循环写得紧凑或者避免使用模板固有其道理。但如果这是你选择一门编程语言的唯一理由，那么你就大错特错了。日常工作中，与其用基于深度 优化的向量化C++语言构建的多核并行异步map-reduce架构去做一个卷积离散傅立叶变换（correlation-DFT），我宁愿用BASIC 来做一个快速傅立叶变换（FFT）。 那么到底应该根据什么来选择编程语言呢？唯一检验标准：是否言而达意。 抛开语言的执行效率和功能等等不谈，一门语言必须能够让你描述自己的意图，不光是对编译器而言，更是对未来的读者而言。我相信软件维护中99%的问 题都是由于最初写代码的人没能准备表述他们的意图造成的。如果言不达意，文档就不叫文档。如果言不达意，UML图就不是UML图。如果无法描述某种数据型 适用于哪些操作符的话，面向对象编程就不是面向对象编程。言而达意不是指C风格的ModifyWindowEx（HWND wnd）不易读而Window.modify（）告诉了你和编译器这个window可以和不可以做什么。关键是要表明你的意图。 Fortran如今已大大落后，因为它用下面这种方式描述一个算式： MOV AX, $5DADD AX, $6FMOV $7F, AX 其实完全可以写成这样： c = a + b 如此你就知道是a加上b，结果存到c，即便你不懂计算机也能看懂。 一个常见的误解是：函数式编程语言表达你要什么（what you want）而命令式编程语言表达你想怎样（how you want）。 这是一种糟糕的理解。因为有时候“你想怎样”恰恰是你想表达的意思。 按照我一贯的博文风格，请你问自己一个基本问题，当面临语言的选择时： “我是否把意思说清楚了？”如果你无法回答这个问题，那么你没有用最佳语言。如果你不得不写文档或者做注释，这说明你的代码没能描述你的意图。看看这个函数原型： char* reverseString(const char *foo); 在缺少关于空指针，空字符串以及其他异常处理文档的帮助下，根本没法理解作者到底想干什么。这不太好。当然，函数内部可能对输入做了无数的验证，但你必须写一堆针对各种特定输入的单元测试以确保你的假设是正确的。 我所指的“把意思说清楚”是什么意思呢？假设C++在原型中支持以下虚拟语法： char* @Nullable reverseString(@NonNullable const char *foo); 函数原型中加上这些注解有两个好处： 1. 你不需要事先测试foo是不是null。编译器保证会给你一个非null。 2. 明确地告诉调用者你不容忍null。这种表述方式编译器能够明白，优秀的静态分析工具可以检测到这类bug，这是C语言做不到的。 虽然这看起来只不过是增强了一下语法，实际不仅如此，它还增强了语义。如此不论是人或是机器就明白foo这个变量不可为null，否则函数很生气，后果很严重。而且，你给这个函数划定了界限，再不用担心foo可否为null了。 |
