《黑客与画家》

今天下载了《黑客与画家》的英文版电子书，读了前两章。其中第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的历史地位。

《黑客与画家》