📌 读完计算机系的研究生课程,我就去了艺术学校,学习绘画。许多人很吃惊:一个喜欢计算机的人,居然还喜欢画画!他们似乎觉得,摆弄计算机和画画是两件截然不同的事情——计算机是冰冷的、精确的、井然有序的,而画画是某种原始欲望热烈狂放的表达方式。
📌 黑客与画家的共同之处,在于他们都是创作者。与作曲家、建筑师和作家一样,黑客和画家都试图创作出优秀的作品。他们本质上都不是在做研究,虽然在创作过程中,他们可能会发现一些新技术(那样当然更好)。
📌 建筑学和工程学之间的界限并不是很分明,但就是存在区别。这表现在“做什么”和“怎么做”:建筑师决定做什么,工程师想出怎么做。
📌 创造优美事物的方式往往不是从头做起,而是在现有成果的基础上做一些小小的调整,或者将已有的观点用比较新的方式组合起来。这种类型的工作很难用研究性的论文表达。
📌 塞缪尔·约翰逊说过,人们对一个作家的评价,需要100年才能达成一致。你必须先等他的那些有影响力的朋友都死了,然后再等他的追随者都死了,才能对他有一个公正的评价。
📌 现在,我意识到自己错了。黑客搞懂“计算理论”(theory of computation)的必要性,与画家搞懂颜料化学成分的必要性差不多大。一般来说,在理论上,你需要知道如何计算“时间复杂度”和“空间复杂度”(time and space complexity);如果你要写一个解析器,可能还需要知道状态机(state machine)的概念;除此以外,并不需要知道特别多的理论。这些可比画家必须记住的颜料成分少很多。
📌 更糟的是,我不是耐心地一步步写出整个程序,确保大体上是正确的,而是一股脑地不管对错,先把代码堆上去,再慢慢修改。书上说,调试是最后的步骤,用来纠正打字错误和疏忽。可是我的工作方法看上去却像编程就是在调试。
很长一段时间内我都为此事沮丧,就像小学里老师教我怎么拿铅笔,我却总是学不会的那种感觉。
📌 你把整个程序想清楚的时间点,应该是在编写代码时,而不是在编写代码之前,这与作家、画家和建筑师的做法完全一样。
📌 编程语言是用来帮助思考程序的,而不是用来表达你已经想好的程序。它应该是一支铅笔,而不是一支钢笔。如果大家都像学校教的那样编程,那么静态类型是一个不错的概念。但是,我认识的黑客,没有一个人喜欢用静态类型语言编程。我们需要的是一种可以随意涂抹、擦擦改改的语言,我们不想正襟危坐,把一个盛满各种变量类型的茶杯,小心翼翼放在自己的膝盖上,为了与一丝不苟的编译器大婶交谈,努力地挑选词语,确保变量类型匹配,好让自己显得礼貌又周到。
📌 科学界的每一个人,暗地里都相信数学家比自己聪明。我觉得,数学家自己也相信这一点。最后的结果就是科学家往往会把自己的工作尽可能弄得看上去像数学。对于物理学这样的领域,这可能不会有太大不良影响。但是,你越往自然科学的方向发展,它就越成为一个严重的问题。
一页写满了数学公式的纸真是令人印象深刻啊。(小窍门:用希腊字母表示变量名会令人印象更深刻。)因此,你就受到巨大的诱惑,去解决那些能够用数学公式处理的问题,而不是去解决真正重要的问题。
📌 如果黑客认识到自己与其他创作者——比如作家和画家——是一类人,这种诱惑对他就不起作用。作家和画家没有“对数学家的妒忌”,他们认为自己在从事与数学完全不相关的事情。我认为,黑客也是如此
📌 大学和实验室强迫黑客成为科学家,企业强迫黑客成为工程师。
📌 发现在他们看来,“黑客”的工作就是用软件实现某个功能,而不是设计软件。在那里,程序员被当作技工,职责就是将产品经理的“构想”(如果这个词是这么用的话)翻译成代码。
这似乎是大公司的普遍情况。大公司这样安排的原因是降低结果的标准差。因为实际上只有很少一部分黑客懂得如何正确设计软件,公司的管理层很难正确识别到底应该把设计软件的任务交给谁,所以,大部分公司不把设计软件的职责交给一个优秀的黑客,而是交给一个委员会,黑客的作用仅仅是实现那个委员会的设计。
📌 大公司为了避免设计上的灾难,选择了降低设计结果的标准差。但是当你排斥差异的时候,你不仅将失败的可能性排除在外,也将获得高利润的可能性排除在外。这对大公司来说不是问题,因为生产特别优秀的产品不是它们的获胜手段。大公司只要做得不太烂,就能赢。
📌 。比如,就算写一个比微软的Word更好的文字处理软件不是难事,但是微软公司有自己的城堡,它的操作系统是垄断的,你根本无法对它构成威胁,它甚至都不会注意到你的存在
📌 黑客如何才能做自己喜欢的事情?我认为这个问题的解决方法是一个几乎所有创作者都知道的方法:找一份养家糊口的“白天工作”(day job)。这个词是从音乐家身上来的,他们晚上表演音乐,所以白天可以找一份其他工作。更一般地说,“白天工作”的意思是,你有一份为了赚钱的工作,还有一份为了爱好的工作。
📌 我们在面试程序员时,主要关注的事情就是业余时间他们写了什么软件,因为如果你不爱一件事,你不可能把它做得真正优秀,要是你很热爱编程,你就不可避免地会开发你自己的项目。
📌 因为黑客更像创作者,而不是科学家,所以要了解黑客,不应该在科学家身上寻找启示,而是应该观察其他类型的创作者。那么,从画家身上,我们还能借鉴到什么对黑客的启示呢
📌 有一件事情是可以借鉴的(至少可以确认),那就是应该如何学习编程。画家学习绘画的方法主要是动手去画,黑客学习编程的方法也理应如此。大多数黑客不是通过大学课程学会编程的,而是从实践中学习,有的13岁时就自己动手写程序了。即使上了大学,黑客学习编程依然主要通过自己写程序。
📌 画家的作品都会保留下来,你观察这些作品,就能看出他们是怎么一步步通过实践学习绘画的。如果你把一个画家的作品按照时间顺序排列,就会发现每幅画所用的技巧,都是建立在上一幅作品学到的东西之上。某幅作品如果有特别出色之处,你往往能够在更早的作品中发现一个小规模的初期版本。
📌 。你不能盼望先有一个完美的规格设计,然后再动手编程,这样想是不现实的。如果你预先承认规格设计是不完美的,在编程的时候,就可以根据需要当场修改规格,最终会有一个更好的结果。(大公司的内部结构,使得它们很难这样做。这是创业公司的又一个优势。)
眼下想必每个人都知道,过早优化是一件危险的事情。我认为,我们应该对“过早设计”也抱有同样的担忧,不要太早决定一个程序应该怎么做。
📌 但是达·芬奇不这样想。他对作品每一部分的认真程度完全不取决于预料中会不会有人仔细看这个部分。他就像篮球巨星迈克尔·乔丹,每一球都一丝不苟,绝不降低对自己的要求。
📌 坚持一丝不苟,就能取得优秀的成果,因为那些看不见的细节累加起来,就变得可见了。当人们从达·芬奇的女性肖像画《吉内薇拉·班琪》前面走过的时候,他们的注意力往往立刻就被它吸引住了,那时他们甚至还没有看到说明的标签牌,没有意识到这是达·芬奇的作品。所有那些看不见的细节合并在一起,就使得这样东西产生了惊人的效果,仿佛上千个细微的声音都以同一个音调在歌唱。
📌 黑客就像画家,工作起来是有心理周期的。有时候,你有了一个令人兴奋的新项目,你会愿意为它一天工作16个小时。等过了这一阵,你又会觉得百无聊赖,对所有事情都提不起兴趣。
📌 消灭bug的过程就像解一道数学题,已知许许多多的约束条件,你只要根据条件对方程求解就可以了。你的程序应该能产生x结果,却产生了y结果。哪里出错了?你知道自己最后肯定能解决这个问题,所以做起来就很轻松,就好像刷墙一样,接近于休闲了。
📌 我认为,这也是多人共同开发一个软件的正确模式。需要合作,但是不要“合”得过头。如果一个代码块由三四个人共同开发,就没有人真正“拥有”这块代码。最终,它就会变得像一个公用杂物间,没人管理,又脏又乱,到处堆满了冗余代码。正确的合作方法是将项目分割成严格定义的模块,每一个模块由一个人明确负责。模块与模块之间的接口经过精心设计,如果可能的话,最好把文档说明写得像编程语言规范那样清晰。
📌 普通黑客与优秀黑客的所有区别之中,会不会“换位思考”可能是最重要的单个因素。有些黑客很聪明,但是完全以自我为中心,根本不会设身处地为用户考虑。这样的人很难设计出优秀软件,因为他们不从用户的角度看待问题。[插图]判断一个人是否具备“换位思考”的能力有一个好方法,那就是
📌 看他怎样向没有技术背景的人解释技术问题。我们大概都认识这样一些人,他们在其他方面非常聪明,但是把问题解释清楚的能力却低下得惊人。如果聚会上外行人问他们“什么是编程语言”,他们会这样回答:“哦,高级语言就是编译器的输入代码,用来产生目标码。”高级语言?编译器?目标码?……如果对方不知道什么是编程语言,那么他显然也不会知道这些概念。
📌 程序必须写得能够供人们阅读,偶尔供计算机执行。
📌 我预言Java也会如此。有人写信说:“你怎么能说Java不会成功呢?它已经成功了。”我觉得这要看你的成功标准是什么。如果标准是相关图书的出版量,或者是相信学会Java就能找到工作的大学生数量,那么Java确实已经成功了。当我说Java不会成功时,我的意思是它和Cobol一样,进化之路已经走到了尽头。
📌 我的判断是,那些内核最小、最干净的编程语言才会存在于进化的主干上。一种语言的内核设计得越小、越干净,它的生命力就越顽强。
📌 编程语言进化缓慢的原因在于它们并不是真正的技术。语言只是一种书写法,而程序则是一种严格符合规则的描述,以书面形式记录计算机应该如何解决你的问题。所以,编程语言的进化速度更像数学符号的进化速度,而不像真正的技术(比如交通或通信技术)的进化速度。数学符号的进化是缓慢的渐变式变化,而不是像真正的技术那样跳跃式发展。
📌 随着技术的发展,每一代人都在做上一代人觉得很浪费的事情。30年前的人要是看到我们今天如此随意地使用长途电话,一定会感到震惊。100年前的人要是看到一个普通的包裹竟然也能享受一天内从波士顿发件、途经孟菲斯、抵达纽约的待遇,恐怕就要更震惊了。
我已经预测了一旦未来硬件性能大幅提高将会发生什么事:新增加的运算能力都会被糟蹋掉。
📌 浪费可以分成好的浪费和坏的浪费。我感兴趣的是好的浪费,即用更多的钱得到更简单的设计
📌 我觉得,放弃字符串类型已经是大家可以接受的想法了。Arc语言已经这样做了,看上去效果不错。以前用正则表达式很难描述的一些操作,现在用回归函数可以表达得很简单。
这种数据结构的扁平化趋势会怎么发展?我极其努力地设想各种可能,得到的结果甚至令我自己都吓了一跳。比如,数组会不会消失?毕竟数组只是散列表的一个子集,其特点就是数组的键全部都是整数向量。进一步说,散列表本身会不会被列表取代呢?
📌 比尔·伍兹曾经对我说,根据经验判断,每增加一个解释层,软件的运行速度就会慢一个数量级。但是,多余的软件层可以让编程灵活起来。
📌 顺便说一句,我不认为面向对象编程将来会消亡。我觉得,除了某些特定的领域,这种编程方法其实没有为优秀程序员带来很多好处,但是它对大公司有不可抗拒的吸引力。面向对象编程使得你有办法对面条式代码进行可持续性开发。通过不断地打补丁,它让你将软件一步步做大。大公司总是倾向于采用这样的方式开发软件。我预计一百年后也是如此。
📌 在学习开车的时候,一个需要记住的原则就是要把车开直,不是通过将车身对齐画在地上的分隔线,而是通过瞄准远处的某个点。即使你的目标只在几米开外,这样做也是正确的。我认为,设计编程语言时,我们也应该这样做
📌 如果把创造一种编程语言看成设计问题,而不是科研方向,那么有何不同?
最大的不同在于你会更多地考虑用户。在设计的时候,一开始总是问:“我为谁设计?他们需要什么?”比如,优秀的建筑师不会先设计,然后强迫用户接受,而是先研究最终用户的需求,然后做出用户需要的设计。
注意,我说的是“用户需要的设计”,而不是“用户要求的设计”。我不想让读者产生一种印象,认为设计师就像厨师一样,顾客点什么菜就一模一样地做出来。艺术的各个领域有着巨大的差别,但是我觉得任何一个领域的最佳作品都不可能由对用户言听计从的人做出来。
📌 有一句话说“顾客永远是对的”,这是指评价优秀设计的标准是看它能够在多大程度上满足用户的需求。如果你的小说没人爱看,或者你做的椅子极不舒服,那么就说明你的作品失败了,就算你的小说(或者椅子)有着最先进的理论指导也无济于事。
可是,让用户满意并不等于迎合用户的一切要求。用户不了解所有可能的选择,也经常弄错自己真正想要的东西。做一个好的设计师就像做一个好医生一样。你不能头痛医头,脚痛医脚。病人告诉你症状,你必须找出他生病的真正原因,然后针对病因进行治疗。
大多数优秀设计是这样产生的,它们关注用户,并且以用户为中心。
📌 如果目标用户群体涵盖了设计师本人,那么最有可能诞生优秀设计。如果目标用户与你本人差别很大,你往往会假定目标用户的需求比你本人的需求更简单,而不是更复杂。低估用户(即使出于善意)一般来说总是会让设计师出错。我怀疑那些设计公共住宅项目(housing project)的建筑师根本没想过自己住在里面会是什么感觉。编程语言也有这种现象。C、Lisp和Smalltalk都是设计者为了自己使用而设计的,而Cobol、Ada和Java则是为了给别人使用而设计的。
📌 为了做出优秀的设计,你必须贴近用户,始终寸步不离,永远站在用户的角度调整自己的构想。19世纪英国作家简·奥斯汀的小说为何如此出色?一个原因就是她把自己的作品大声读给家人听,所以她就不会陷入孤芳自赏难以自拔的境地,不会长篇累牍地赞叹自然风光,也不会滔滔不绝地宣扬自己的人生哲学。(事实上,奥斯汀还是在小说里宣扬了自己的人生哲学,不过她把它编进故事之中,而不是直接像贴标签那样讲出来。)你可以随便找一本平庸的“文学”读物,想象一下把它当作自己的作品读给朋友们听,这样会让你真切地感受到那些“文学”读物高高在上的视角,读者必须承受所有沉重的负担才能阅读这些作品。
📌 与之对照,还有另一种软件设计思想,也许可以被称为“万福玛丽亚”模式。它不要求尽快拿出原型,然后再逐步优化,它的观点是你应该等到完整的成品出来以后再一下子隆重地推向市场,就像圣母玛丽亚降临一样,哪怕整个过程漫长得像橄榄球运动员长途奔袭、达阵得分也没有关系。在互联网泡沫时期,无数创业公司因为相信了这种模式而自毁前程。我还没听说过有人采用这种模式而获得成功。
📌 我的一位美术启蒙老师告诉我:如果你觉得画某样东西很乏味,那么你画出来的东西就会真的很乏味。假设你必须画一幢建筑物,你决定从每一块砖头开始画起。你觉得自己可以坚持下去,但是画到一半的时候突然感到很厌倦,于是你就不再认真观察每块砖头并画出它们各自不同的特点,而是以一种机械重复的方式草草地把砖头画完了事。这样一来,你的作品效果就很差,甚至还不如一开始就不采用写实手法,只是若隐若现地暗示砖头的存在
📌 大多数画家是先画一个草图,然后再逐步加工。如果你采用这种方式,那么从理论上说,你每天收工的时候都可以看到整体的效果,不会对最后的成品一点感觉都没有。跟你说实话吧,画家之间甚至流传着一句谚语:“画作永远没有完工的一天,你只是不再画下去而已。”第一线的程序员对于这种情况真是再熟悉不过了。