写作与思考2010dreamsongs.com
Richard P. Gabriel：Lisp 的艺术与写作
Richard P. Gabriel: The Art of Lisp & Writing
导读
这是 Richard P. Gabriel 谈 Lisp 与写作共通之处的一篇文章：两者都不是先定好全部规格再执行，而是在一个"部分可运行"的状态里反复试验、逐步成形，表达力和迭代比"早早钉死决定"更重要。对写作者来说，它提供了一条把初稿当原型、靠短反馈回路推进的实用思路；评论区也补上了对这一类比的质疑。
可以直接用的写作要点
- 01
把初稿当成"部分能跑的系统"：先写出粗糙但完整的版本，再从试读中发现设计问题，而不是开篇就把所有设定钉死。
- 02
一次只推进一句或一小步；故事的"状态"小、反馈回路短，所以你可以把整体放在脑中持续修改。
- 03
选择允许你随时改动的表达方式与工具（语言、结构、体裁），表达力往往比"早做决定"更决定成品。
- 04
类比要落到可验证的具体经验上：真正让迭代奏效的是每次试验得到的确定知识，而不是"写作是艺术"这类空泛说法。
HN 评论精选
表达力与"早定决策"的取舍不能简化成静态/动态类型之争；多试不同语言与形式本身能拓展思维。
正如 Paul Graham 指出的，Lisp 与 Java 的差别在于：Lisp 用来处理计算的想法与表达，Java 用来表达已完成的程序。Java 要求你早早把决定钉死；一旦钉死，类型声明、编译器和运行时就会尽最大努力让你难以更改这些假设，仿佛所有这类改动都是你不小心犯的错。不过这段话里潜藏着"静态类型很糟糕"的暗流，我未必同意：Haskell 就很有表达力，静态类型也未必妨碍原型开发。Gabriel 说自己自 1960 年代以来只用 Lisp 做专业编程——恕我直言，也许他该试试别的：Haskell、Erlang、Factor 能以 Common Lisp 未曾有过的方式拓展思维。
plinkplonk查看英文原文
"The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs. As James says, Java requires you to pin down decisions early on. And once pinned down, the system which is the set of type declarations, the compiler, and the runtime system make it as hard as it can for you to change those assumptions, on the assumption that all such changes are mistakes you're inadvertently making." Lisp vs Java is one thing but there is an undercurrent of "static typing is terrible" running through this paragraph (and others). I am not sure I agree. Haskell for example is very expressive(at least to me). And I am not sure a static type system gets in the way of "prototyping" much. "Lisp, of course, and especially Common Lisp are my languages. Not since the 1960s have I programmed professionally in a language other than Lisp." With all due respect to Richard Gabriel, (and this probably blasphemy) perhaps he should? Haskell or Erlang or Factor are mind expanding in ways Common Lisp never was. (Not to deride Common Lisp, but I am tired of people implying it is some kind of unsurpassed acme of language design excellence)
无论写作还是编程，改动都是一小步一小步来的；写作状态小、反馈回路短，所以能整体在脑中迭代。
我们其实更容易把握"静态"的东西。即便在写作中，故事也得一句一句写；概念中途变了，重写同样要一句一句来——那个颠覆一切的突破性想法，本身通常也只是一句话。编程里我们改两行、再跑一次，基于已知可靠的库，先在纸上构想再实现。关键是反馈回路：小说作者的反馈回路短，故事的"状态"小，没有循环递归带来的复杂度爆炸，进展可以整个装在脑子里；程序员的反馈回路更长，因为她不指望自己在脑中维护整个程序，而是让计算机跑出来再显示结果。动态性优化的正是这种增量推进：程序一直跑到撞上无法调和的错误那一点，然后你手上还有多个选项。
chipsy查看英文原文
I'm pretty sure that Lisp isn't as worthy as Gabriel paints it, for this simple reason: We grasp the static-verse more readily than the dynamic. At most levels of work, we aren't actually making enormous changes all at once - even in the writing analogy, a story has to be written one sentence at a time, and if the concepts start changing partway through, the rewrite has to be done....one sentence at a time. The breakthrough concept that turns everything on its head is usually itself just one sentence. In programming, we change two lines and then run the program again, we build on known, tested libraries and languages, we develop a concept on paper and then implement it. And because these things are built on a small foundation of logical concepts, we can build the language to ensure ever-greater levels of self-consistency that would otherwise only be manifested at runtime. Feedback loops. The fiction writer has a short feedback loop - the "state" of a story is small - no explosions of complexity as one would get with loops or recursion - so its progression can be kept in her head. The programmer has a longer feedback loop, because her expectation is not to maintain the entire progression of the program in her head, but to let the computer do it and then display the results in some manner. Dynamicness optimizes the feedback loop for greater incrementalism: the program runs until it hits any one point where an irreconcilable error is encountered, and then multiple options are available to fix the error and even let the program continue. Staticness optimizes the feedback loop for "batch" error-checking: the programmer writes a full body of code she thinks is correct, with no run/test cycle to speak of, and then gets all the errors at once. When the program compiles, it works. Since we can't implement either ideology perfectly, it's probably best to have some of _both_.
用"艺术"来类比工程或写作是空泛的；真正让迭代有效的是实验带来的确定知识。
原文说"软件设计问题大多只能靠对部分运行的系统做实验来解决，工程历来如此，不管我们多希望它像科学而非艺术"——这个说法不好。工程的本质是确定性的知识，即科学的、逻辑的知识；这不是说它排斥别的东西，而是说这才是它决定性、根本的特征。实验恰恰产生最具体的确定性知识，科学研究提供宽泛的通用技能，实验为具体任务补上缺口；如果工程不根本关乎确定性知识，实验根本不会奏效。把工程和软件跟艺术挂钩价值不大：按我对美学哲学的了解，艺术与工程没有实质、有用的对应，何况"艺术"本身含义模糊。工程的极限是演化而非艺术——没有知识时工程设计无法运作，演化才是出路。
hxa7241查看英文原文
> ". . . most design problems we face in creating software can be resolved only through experimentation with a partially running system. Engineering is and always has been fundamentally such an enterprise, no matter how much we would like it to be more like science than like art." This is not a very good way of putting it. The essence of engineering is determinate knowledge, i.e. scientific, logical knowledge. That is not to say it excludes other things, or that that essence alone is sufficient, just that it is the definitive, distinctive, fundamental feature. Experiment produces determinate knowledge -- the most specific, detailed kind. Scientific research produces the broad, general know-how, and experiment fills the gaps for a particular task. If engineering were not fundamentally about determinate knowledge, then experiment could not work. The knowledge produced by the experimental trial would not even have the generality to transfer to the intended use. Associating engineering and software with art seems of little value. From what I remember of aesthetic philosophy, art does not have substantial, useful, or perhaps any correspondence with engineering -- let alone the vagueness of what art is anyway. One cannot fault the real content of the article, but the arty leaning is ultimately empty. The limit of engineering is evolution, not art. When there is no knowledge, engineering design can't work, and instead evolution is the way. Proof of the effectiveness of that alternate approach is all around.
同类还值得读
不要想好再写，要写来思考
Don’t think to write, write to think
这篇短文主张不要把写作当成思考完成后的记录，而要把写作本身当作思考的工具：动笔的过程会逼出想不清楚的地方。
写作与思考2022 · 553 分 · 145 评4 条写作要点编辑精选写作即思考：学会自信地写作
Writing Is Thinking: Learning to Write with Confidence
这是一篇讲“写作即思考”的博客：作者认为写作不是把想好的东西誊写出来，而是借助写作本身把想法想清楚，因此写作者应当建立信心、敢于先写烂稿。
写作与思考2019 · 529 分 · 83 评4 条写作要点编辑精选如何用写作来思考
How to think in writing
这篇文章讨论的是「用写作来思考」：作者认为写作不只是把想清楚的东西表达出来，更是想清楚本身的工具——文字落在纸上，你才有机会看见自己思路里的跳跃、含混和漏洞。
写作与思考2024 · 424 分 · 120 评4 条写作要点编辑精选写作，帮你逃离默认的人生设置
Write to Escape Your Default Setting
文章的核心主张就写在标题里：写作是帮你逃离「默认设置」的手段——日常的思维和表达都有惯性默认的默认模式，而落笔能逼你跳出来，重新看清自己到底在想什么、要说什么。
写作与思考2025 · 407 分 · 93 评4 条写作要点编辑精选写作就是思考
Writing is thinking
文章以“写作即思考”为题，讨论写作不只是把已有想法记录下来，而是帮助澄清、组织和推进思考的过程。
写作与思考2025 · 330 分 · 128 评4 条写作要点编辑精选