《黑客与画家》第2章读书笔记

今天下载了《黑客与画家》的英文版电子书，读了前两章。其中第2章Hackers and Painters，有很多有趣、发人深省的观点。摘抄下来，再加上一些我的思考。

很多人认为黑客和画家不相干，比如黑客应该是冷酷的、精确的、强调方法的。而画家则应该是激情地表达内心的原始冲动。 作者Paul Graham认为黑客和画家是很相似的。相似点在于，他们和作曲家、建筑师、作家一样，都属于“创造者”，创造美好的东西。

作者说他不喜欢“计算机科学”这个词，他觉得它把很多原本无关的东西杂糅在一起了。主要包括三类人：1)那些挂着“计算机”的招牌，实则做着数学工作的人。 2)那些研究计算网络、编译原理等计算机学科的人(这个应该是大学里通常的计算机学科研究人员) 3)作者认为的“黑客”：对于他们来说，计算机只是一个工具，就像混凝土对于建筑师、画笔对于画家一样，是他们 实现伟大创意的工具。

作者认为把第1)类和第3)类人生硬地归于“计算机科学”，虽然在行政管理上有好处，但是是不恰当的。对于黑客，他们做的并不是实验科学。 他们最重要的目的是设计软件，而非发表论文。事实上，在工程上很优美的东西，往往不适合发表研究论文。工程上的东西往往是对 现有的东西做了微妙但重要的改变，或者将各种主意组合在一起，并不符合对论文对工作的原创性的要求。

因此，用“发表论文”来衡量黑客固然可操作性强，但是却有失公允。唯一的恰当评价方式是“时间”，优美的东西会历久弥新，而丑陋的东西则会被时间扬弃。 但是公平恰当的评判所需要的时间跨度甚至可能超过人的寿命。所以黑客们需要接受这样的一个事实，那就是对于他们的评判不可避免地会有“随机性”。

另外一个将黑客归于“计算机科学”的负面作用是，这会影响到黑客对于自己的评价。作者提到他在对大学期间，会时常觉得他需要学习更多的理论，在考试结束的 后三周将所有的东西忘得干净是一件罪恶的、不可饶恕的事情。后来作者发现这样的错误，作为一个黑客，对于理论的学习”够用即可”： 他需要了解算法的时空复杂度，或者在需要写parser的时候了解些状态机的知识。这就像画家也需要对和绘画有关的化学懂一些，但是“懂一些”就够了，他们没必要像化学家一样精通。

作者认为，诸如画家这样的创造者，比起计算理论等挂着“计算机”招牌的领域，能给一个黑客更大的启发：

画草图

首先，黑客同画家一样，都需要画草图、做快速原型。我们没有必要在开始写代码之前，在纸上把思路整理好。在实践中，作者经常是先写一些零零散散的、 “割裂”的代码，然后再整理成型。Debugging也并非是编程结束之后排错、检查疏漏的步骤，它理应作为编程的一部分。就像画家、作家这些“创造者” 一样，黑客也是在写代码时对于在他们正在“创造”的程序有了更深、更全面的认识。好的编程语言应该可以很好地辅助这个思考的过程。它并不是仅仅用来呈现我 们的思考的结果，而是作为对程序认知的手段。因此，一个好的编程语言应该是支持“涂涂改改”的。

避免对数学的盲目崇拜

第二点，认识到黑客和画家之间的相似性，可以避免我们对于数学盲目的崇拜。在数学形式上优美的问题，很可能不是实际中重要的问题。

“白天工作”

如果说大学或者研究室里并不能让黑客做他们真正该做的东西，那么也许公司可以。但是作者以他在Yahoo的经历告诉我们，对于大公司来 说，Hacking的含义是“实现”，而非“设计”。程序员最重要的使命是将产品经理的设想变成代码。大公司这样做，是为了减少“设计”和“实现”间的 “标准差”，从而尽可能地规避风险。与其将产品的未来托付给黑客的(往往是不确定、不可控的)创意，倒不如仅仅让黑客们负责实现设计好的构想。

黑客们可以选择“创业”(start-up)，那里是他们实现伟大创意的归宿。但是创业亦有不好之处，一是容易为琐事分神，很难专注于 Hacking本身。二是，黑客们本身的兴趣往往和赚钱的软件没有“交集”。比如，设计编程语言本身很有趣，但是市场并不对此“感冒”，更不会给你分文报 酬。价格是由供需关系决定的，市场对于那些能解决用户实际问题的事情更感兴趣。从这层意义上来讲，设计一个编程语言反而不如为某公司解决怎样让遗留数据库 连接服务器。

对于黑客，和对于所有的创造者一样，解决此类难题的终极答案是：有一份“白天工作”，它帮你挣钱；有一份“夜晚工作”，它满足你的兴趣和好奇心。

几乎每一个创造者，在他们的生涯早期，都会有一份这样的“白天工作”。比如说对于音乐家，他们白天可能在录音店；画家白天会在画廊打工；作家为了维持生计甚至可能会帮某公司写广告甚至是“软文”。

对于黑客来说，“白天工作”往往是在某软件公司、互联网公司上班，而“夜晚工作”则是做自己的项目，参与到开源软件中来。很多的公司不会鼓励雇员参与开源软件项目，而在作者的公司Viaweb，他们则不会考虑那些没有开源贡献的人。Viaweb在招聘时，最重要的考虑就是这个人在业余时间做了一些什么。

Paul接下来说了一句振聋发聩的话：

如果你不爱一件事，你不可能做好。如果你很爱Hacking的话，那么你毫无疑问会在做自己的项目。

我没有做到，没有过任何的开源软件的贡献，自己的项目做得很少。我做的大部分东西都是课程作业、实验室项目、或者在实习公司里老板给的项目。而且我承认Paul一针见血地指出了我的症结所在：“不够爱”。 我认识的那些大牛们，那些对于编程狂热、痴迷、无比热爱的人，都在这些年里做着很多非强制性、非功利性，无商业目的、完全出于自身热爱的项目。他们很多比 我小，却早已小有成绩。而且在做这些项目的同时，他们越来越“牛”，认识了更多更“牛”的人，将那些不够热爱的人(比如我)，远远地甩在了身后。

通过“做”本身学习如何去做

画家通过画画成为画家，黑客也需要通过Hacking来成为黑客。

临摹！

此外，画家需要浸淫在博物馆里临摹大师之作以期提高，黑客也需要阅读优秀的程序-不仅仅关注它们做了什么，更需要去阅读源程序。

精化

伟大的作品往往发轫于草图，然后历经无数的修改，有时最初的设计甚至需要推倒重来。程序也是。黑客需要意识到设计不可能在一开始就完美。“过早优化”是万恶之源，“过早设计”也是。



这听起来像个悖论：一个伟大的绘画需要比它必须达到的程度更伟大。达芬奇在画Ginevra de’s Beci时，将后面灌木丛林的每一个叶子都画得纤毫毕现。大部分的画家在画灌木丛林时，会因为没有人会仔细看背景，而草草了事。但达芬奇不是这样，他绘画 认真与否并不取决于他预期别人会不会仔细看。他对自己的要求冷酷无情，这一点上，Michael Jordan、Kobe Bryant也是这样。很多成功的人其实都是这样的偏执狂。

好的软件，也需要这样的一种对美的狂热的、近似于偏执的追求。如果我们深入阅读一些伟大软件的源码时，我们会发现甚至那些从没有人会去阅读的部分都很完美。作者说，他看到那些缩进或者变量命名糟糕的代码会抓狂(我有时也是这样)。

有起有落

如果把黑客仅仅看成一个将设计变成代码的“实施者”，那么这个工作就像挖下水道一样，可以按部就班地进行。但是如果将黑客视为创造者，我们必须将灵感、激情等因素纳入考虑。有时，我们会像打了鸡血一样，一天工作16个小时，而有时，工作会变得索然无味。

因此，作者建议攒下一些简单的活儿，当工作陷入困顿的时候，再拿出来做。对于黑客来说，这些简单的活指Debugging(除错)。 Debugging是一件目的特别明确的事，假设程序该做x，但是它做了y。什么错了？我们终究能找到出错的地方的，这就像画家刷墙一样轻松。

合作

画家在完成画作的时候，可能会需要合作。黑客们也是这样。最好的合作方式是：将项目划分为边界清晰的模块，各个模块有专人负责，模块之间的接口定义清晰。

“同情心”

米兰.昆德拉说在《不能承受的生命之轻》里说“同情”是最高境界的情感想象力，是一种能够与他人共甘苦，同时与他人分享其他任何情感：快乐、忧愁、 幸福和痛苦的能力。作者也这样认为，“同情”是区分一个好的黑客和伟大的黑客的最重要的因素。很多聪明的黑客，并不会从用户的角度去看待问题。

对于黑客，“同情”包括两层含义：1)程序应该是自解释的，符合一个未读过手册的用户出于直觉的心理预期。在这方面，苹果的Macintosh是典 范。2)源代码也应该是自解释的，代码只是偶尔需要在机器上执行，大部分时间都是用来写给人读的。相信很多黑客都有过读自己六个月前写的代码，却发现不知 所云的糟糕经历吧。

Hacking正当时

每项技能，从它起源，到逐渐赢得人们重视，就像来自于遥远星系的光亮一样，往往有时间差。500年前达芬奇们之于绘画，莎翁们之于戏剧，简.奥斯汀们之于文学创作，这些伟大的人，定义了绘画、戏剧、文学的历史定位，至今仍无法超越。

当一项技能出现的时候，欣喜若狂的人们会在最初的几十年探索出最多的可能性来。现在，毫无疑问，正是属于黑客们的时代。我们现在所做的，将塑造Hacking的历史地位。