最近机缘巧合，再次重读了《黑客与画家》，特此分享。

摘要

这种类型的书，实际上是需要一定的项目背景才能看懂。假如你没有多个从零到一的项目经历，你可能只看到“哇，用Lisp的速度是其它语言的XX倍”，“大公司真是官僚啊”这样的感叹。实际不然，它里面很多观点是必须实践才能了解的。

同时也不要过于诉诸权威，或者依赖这类书籍带来的虚假获得感，假如你只有通过实践才能最终印证书中的观点，那么它是一个存粹的不可证伪命题----为何不如直接去看“Cookbook”的搬砖实践或者形而上思考呢？

综上，本书定位更加类似作者创业过程中的随笔。即使作者本人十分权威，书的本体信噪比仍然很低，类似于偶尔翻一番，然后刷新下思路的书本。

“计划”还是“绘画”

作者在文中强调了自己的编程习惯：先什么也不规划就开始写代码，边写边改，能跑起来后再进行profiler分析提高速度，如同作家或者画家在作品上反复涂改一样，一半的构思是在写作中产生的，具有发散的特点。

相反，在世界五百强的大公司中，强调的是“业界规范”，比如用“敏捷”来让你天天汇报，用“可信”来控制编码的条条框框，让你先输出设计规格，输出工时估算陷入会议中，然后迅速招聘一批应届生开搞，最后销售包装。然而这样的产品可能并不缺客户，因为客户需要“低标准差”与“业界规范”。再比如刷算法题，本质上也是一种记忆驯化，你真的bug-free且在20分钟想出大师们的毕生成果吗？

“绘画”与“规范”这两种场景并没有矛盾，它们的核心都是输出流程或者手册（比如MUJIGRAM）。然而

• 就算是画家这种搞艺术的场景，深圳的大芬村也能做成画家流水线。
• 任何项目在完成高阶思路后，90%的代码翻译与客服工作可能都是非常无聊的，就算用LISP也有CRUD。
• 想要达到作者标准的“全明星”估计只有硅谷有，至少在深圳这种地方连Senior都很难招的。

我们可以得出一个结论，作者强调了“软件设计”作为新兴领域下的创业优势，“只用更少的人、更少的钱，就可以把软件写出来，并且开始运作“，这种场景下少数几个人合作是可以做到的，但是长期看只有新兴领域需要这种手工艺人群体，传统领域基本上很难竞争了。

自我限制的“电篱笆”

作者提到，在创业场景下，很多创业者

• 不懂得管理企业
• 害怕与大公司竞争

其实在软件领域，尤其是新领域，大公司的优势极为有限

• 效率低下：流程多，决策链长，动员能力弱，不愿意承担决策责任
• 可度量：公司难以度量具体的贡献

关于这个场景，个人见解如下，它类似德勒兹（Deleuze）笔下的“战争机器（War machine）”与“游牧民族（nomad）”：

• 如果是成熟的领域（比如制造/半导体，民宿，甚至CRM软件），那么很可能是重资金或者技术密集型领域，法律规范也非常健全，流程成熟透明，市场要求必然是成本控制与流程优先，甚至利润率就靠压成本的差价产生。没有短板就是最好的优势。
• 而在新领域，最贵的成本是时间，尤其是需要快速转向实现快速再投入的领域。机器等资金费用相比起来反而不贵，比如10台 t4g.2xlarge(8U32G) 的机器，一年也不超过10万RMB，而一个五年经验的Java开发可能需要60万的Package，如果不精确利用长处，而是总是去克服短板，对大家都是失败。

LISP的使用场景

在本文中，作者强调了LISP的宏编程能力，即代码和数据结构混合在一起，可以递归自编译的高度抽象方案，尤其是在案例中比另外的大型企业的开发速度有了显著提高，同时作者后面也强调了库函数的作用

• 高度抽象的编程语言：少即是好的。如同画家一样，核心都在思路上。任何软件做到最后都会实现解释器/Low-code。
• 丰富精简的库函数：泛指reusable components，更近一步，托管的SaaS服务/前端JSX/JSP都算库函数。

作者在这里强调的是利用灵活的语言和框架，类似于“10倍速”的定义，但是并不是使用LISP就能确保成功了。你甚至可以参考作者的Y Combinator下所投资的创业公司，它们使用LISP作为秘密武器的团队几乎没有。比如可以直接翻阅这些新公司的技术选型，因为很多开发者相关的项目都是开源的。

再比如王垠就在BLOG中说过

比如很多人崇拜的 Y Combinator，它的创始人 Paul Graham 写过 Lisp 的书（比如《On Lisp》），写过很多文章比如“黑客与画家”，引得许多人膜拜。然而 Paul Graham 写的 Lisp 书却是没有深度的，实际上他并不真懂 Lisp。

我的个人观点

• 理论角度上自学下LISP当然很好
• 大部分场景下，核心工作量仍然是库函数作为主体，语言反而不重要，你甚至可以用Groovy进行混合编码。
• 业务逻辑侧可以用Policy as Code等引擎/low-code等流程作为灵活组合的方案，但是要求可调试与可测试
• 冷门语言招聘成本非常高，这种团队要么很强（比如EDA级别的Chez Scheme），要么半天招不到人（比如兼具JVM生态和Lisp灵活性的Clojure）。靠谱的人基本上是靠猎头和内部推荐的。甚至专门提供快速开发工具的供应商，也全部选型采用JS代码而非LISP作为low code。

据我所知

• 某个知名的YC公司的确开始是使用的Rails等支持宏编程的框架来开发的，但是等到项目稳定后，又开始招人写SpringBoot进行重构了，这个是大型化过程中不可避免的课题。
• 对知识要求极高的芯片仿真，当前也是Scala–(Chisel)–> Verilog–(VCS)–> C的技术架构，也没有使用LISP，本质上也是将抽象问题扔给JVM了，当然Synopsis编译器内部是否有使用LISP，就不得而知了

总结

总体上来说，这些章节的观点还是有很多预制条件的。

• 当前编程瓶颈越来越低，甚至你自己搭建比云服务还贵，因此尽可能找SaaS等技术组合降低开支。
• 个人的项目经验：快（可批量放大，leverage）、强运营（可度量）且保密。这三条是很难的，需要有人带。