yinwang 网摘

什么是“对用户友好”

我们从心理的角度来分析一下为什么有人对这种“对用户不友好”的事实视而不见，而称抱怨的用户为“菜鸟”。这个似乎很明显，答案是“优越感”。如果每个人都会做一件事情，如何能体现出我的超群智力？所以我就是要专门选择那种最难用，最晦涩，最显得高深的东西，把它折腾会。这样我就可以被称为“高手”，就可以傲视群雄。

爱因斯坦说：“Any intelligent fool can make things bigger and more complex… It takes a touch of genius - and a lot of courage to move in the opposite direction.”

计算机科学课程

这就是对话的力量，这让我再一次想起“Little 系列”书籍。为什么《The Little Schemer》是对话的形式，为什么它用那么短的篇幅，可以教会我比普通书籍多很多的东西？我一直很好奇这个现象。

有一次我问 Friedman，你的书怎么都是这种对话风格啊？这叫什么 style？他笑了：“这叫 little style！” 后来我发现，这种对话式的教学方式几千年前就出现了，叫做「苏格拉底方法」。

苏格拉底承认他自己本来没有知识，而他又要教授别人知识。这个矛盾，他是这样解决的：这些知识并不是由他灌输给人的，而是人们原来已经具有的；人们已在心上怀了“胎”，不过自己还不知道，苏格拉底像一个“助产婆”，帮助别人产生知识。

孔夫子似乎也用了不少对话式的教学。不过孔子的方式是学生提问，老师只是回答，像顾问似的；而苏格拉底的方式是老师提问，学生回答。方向是相反的。

如何阅读别人的代码

所以我从 PyTorch 的代码里面学到了什么呢？什么都没有。我只看到各种软件开发的误区在反复上演。如果他们在早期得到我的建议，根本不可能把代码组织成这种样子，不可能有这么多的宏处理，代码生成，DSL。

很多人以为看大型项目可以提升自己，而没有看到大型项目不过是几十行核心代码的扩展，很多部分是低水平重复。几十行平庸甚至晦涩的代码，重复一万次，就成了几十万行。看那些低水平重复的部分，是得不到什么提升的。造就我今天的编程能力和洞察力的，不是几百万行的大型项目，而是小到几行，几十行之短的练习。不要小看了这些短小的代码，它们就是编程最精髓的东西。反反复复琢磨这些短小的代码，不断改进和提炼里面的结构，磨砺自己的思维。逐渐的，你的认识水平就超越了这些几百万行，让人头痛的项目。

所以我如何阅读别人的代码呢？Don’t。如果有条件，我就让代码的作者给我讲，而不是去阅读它。如果作者不合作，而我真的要使用那个项目的代码，我才会去折腾它。那么如何折腾别人的代码呢？我有另外一套办法。

Talk is not cheap

人们应该可以平等自由的表达自己，不受这种无谓的教条压制。每当有人一针见血，指出我迷惑已久的问题的要点，豁然开朗的时候，我会很清楚的记得这个人。我会尊敬他，在合适的时候给予他回报。就算没有给我新的想法，要是他说出一些我曾经琢磨很久才想清楚的点，或者给了我另一个角度的观点，我也会记得他。这些给我指出正确方向的人，我不需要看他们的代码，我不以最终的“成果”来衡量他们的价值。想法和观点在我这里是高于代码的。

理性的力量

他说，你应该等自己有了地位再说那些话，那时候听你说话的人会多一些。我当时给了他一个礼貌而中肯的回复。我告诉他：“我不需要到达所谓的‘地位’才说话。我说的话，价值就在这些话自己身上，它们不需要依附于任何人的地位或者名气来起作用。实际上，许多人都在听我说的话，因为他们理解了其中的内容。”

如何掌握所有的程序语言

所以一般说来，一种好的语言，它所特有的新特性，终究不会超过一两种。如果有个语言号称自己有超过 5 种新特性，那你就得小心了，因为它们带来的和可能不是优势，而是灾难！

有个大师说得好，完全理解一种语言最好的方法就是自己动手实现它，也就是自己写一个解释器来实现它的语义。但我觉得这句话应该稍微修改一下：完全理解一种“语言特性”最好的方法就是自己亲自实现它。

注意我在这里把“语言”改为了“语言特性”。你并不需要实现整个语言来达到这个目的，因为我们最终使用的是语言特性。只要你自己实现了一种语言特性，你就能理解这个特性在任何语言里的实现方式和用法。

DSL 的误区

我觉得大部分 DSL 都是不应该存在的，我们应该尽量避免创造 DSL。

绝大部分 DSL 的存在，都是因为设计它的人没有理解问题的本质，没有意识到这问题并不需要通过设计新的语言来解决。很多人设计 DSL，是因为看到同类产品里面有 DSL，所以就抄袭照搬。或者因为听说 DSL 很酷，设计出 DSL 会显得自己很厉害，很有价值。同时，设计 DSL 还可以让同事和公司对自己产生依赖性。因为有人用我的 DSL，所以公司需要我，离不开我，那么 job security 就有所保证 ;)

我并不是在这里鼓吹 Scheme，搞宣传。正好相反，对 Scheme 的宏系统有了深入理解之后，我发现了它带来的严重问题。内行人把这个问题称为“新语言问题”（The New Language Problem）。

因为在 Scheme 里实现一个新语言如此的容易，几行代码就可以写出新的语言构造，改变语言本来的语义，所以这带来了严重的问题。这个问题就是，一旦你改变了语言的语义，或者设计出新的语言构造，人们之间的交流就增加了一道障碍。使用你改造后的 Scheme 的人，必须学习一种新的语言，才能看懂你的代码，才能跟你交流。

如果一个语言，每当用户需要用它表达任何东西，都得去麻烦它的设计者，甚至需要给这个语言增加新的功能，那这个语言就不应该存在。

什么是现实理想主义者

喜欢删掉别人代码重写的人，也许有很高的智力，却缺乏智慧。

“谢谢你帮助我们保持了常理和理智，把事业推向前进。我们会怀念你的！”

经验和洞察力

我是一个身上不贴任何标签的，不能被任何头衔所局限的，真正有价值的人。

经验虽然不是最重要的，然而还是有必要的。很多技术你不能完全不碰它，然而一碰就明白了。但如果没有实际的问题，你又会没有动力去接触那些技术。所以我一直在做的一件事情，就是接触各种技术，然后利用洞察力来获得越来越多的经验。

数学和编程

如果你再多看一些数学书，就会发现这只是数学语言几百年累积下来的糟粕的冰山一角。数学书里尽是各种上标下标，带括号的上标下标，x，y，z，a，b，c，f，g，h，各种扭来扭去的希腊字母，希伯来字母…… 斜体，黑体，花体，双影体，……用不同的字体来表示不同的“类型”。很多符号的含义，在不同的子领域里面都不一样。有些人上一门数学课，到最后还没明白那些符号是什么意思。

谈程序的正确性

这些人其实不明白一个重要的道理：你得先写出程序，才能开始谈它的正确性。看一个程序好不好，最重要的标准，是看它能否有效地解决问题，而不是它是否正确。如果你的程序没有解决问题，或者解决了错误的问题，或者虽然解决问题但却非常难用，那么这程序再怎么正确，再怎么可靠，都不是好的程序。

DRY 原则的误区

简言之，DRY 原则鼓励对代码进行抽象，但是鼓励得过了头。DRY 原则说，如果你发现重复的代码，就把它们提取出去做成一个“模板”或者“框架”。对于抽象我非常的在行，实际上程序语言专家做的许多研究，就是如何设计更好的抽象。然而我并不奉行所谓 DRY 原则，并不是尽一切可能避免“重复”。“避免重复”并不等于“抽象”。有时候适当的重复代码是有好处的，所以我有时候会故意的进行重复。

设计的重要性

很多人自己的设计有问题，太复杂不易用，到头来却把责任推在用户身上，使用类似“皇帝的新装”的技巧，让用户有口难言。

我为什么离开 Cornell

“Cornell 说要教你游泳，就把你推进池塘里，任凭你扑腾挣扎。等你快扑腾到岸边的时候，它忽然拿起一块大石头砸在你头上，然后继续等着你上岸。当你再次接近岸边的时候，它又拿起一个榔头敲在你头上，这样你就可以死了，可是 Cornell 仍然继续等着你游上岸边……”

所谓的“牛校”，恐怕都是这样吧。学生对于它们只是一种成为“牛校”的工具。你拼着命要进来，好我让你进来。但是我不教你，我让你拼死的做作业。如果你做出来了，我就拿最偏最扯淡的试卷来考你。如果你通过了所有这些，那我就给你一个学位。你得到了这样的“荣誉”，自然就会说“我的学校很牛”。你不敢说它不牛，因为那样就是说你也不牛了。所以这样的学校其实什么也不用干，你能学会东西能毕业，全都是靠你自己，到时候你却要把功劳都归到学校头上。天底下就是有这样好的生意。

我和 Google 的故事（2012 年原版）

最让我受不了的其实是 Google 的气氛。总体感觉就是过度“和谐”，没有人说真话，以至于你不知道什么好，什么不好。很多文档，视频，活动都挂着“Google Confidential”的标签。等你去看了，却发现相当幼稚，其实是众所皆知的东西，没有什么机密可言。可是大部分的实习生们却有一种受宠若惊的感觉，或者假装有这种感觉。每个星期五，都会有一个“TGIF”，两个创始人会像主持人一样组织一个大会。本来无可非议，但是总感觉气氛过于群情激昂了，有点像文化大革命时候念红包书的感觉。好不容易大家聚在一起，总是在听新闻发布，不然就是谈工作。真正大家一起玩的 party，却非常稀少。所以一些别的公司的人都在疑惑，Google 的员工到底有没有下班的时间。