写作与思考2017gigamonkeys.com
代码不是文学（2014）
Code is not literature (2014)
导读
这篇讨论代码能否像文学一样被阅读：作者认为读代码更像做科学实验而非读散文，但评论者用《Physically Based Rendering》等例子说明代码与解释性文字可以结合成可读的作品。对写作者而言，它提醒我们多数写作是功利性的，只有少数值得追求美感，而读者往往需要主动参与而非被动接受。
可以直接用的写作要点
- 01
多数写作和代码一样先求"能用"，再谈"好看"，不必对每篇文字都抱审美期待。
- 02
把示例与解释性文字放在一起（类似文学化编程），让说明和例子互相支撑，比单丢一堆"方程"更易读。
- 03
不要假设读者会线性读完，设计出让读者能动手验证、修改的结构，理解才真正发生。
- 04
想写得优美是一回事，有没有能力是另一回事，审美追求需要匹配相应的技艺训练。
HN 评论精选
代码可以像文学，前提是把代码和解释性文字放在一起，而不是只丢给读者一堆"方程"。
代码不像文学，就像方程不像数学。把数学书里所有方程抽出来、扔掉文字，那就是我们写程序的方式——只剩方程。但看看《Physically Based Rendering》，它拿了奥斯卡，也该拿普利策：全书源代码都在书里，而且相当可读。或者《Lisp in Small Pieces》，一个完整的 Lisp 系统配着启发性文字。你的困惑源于 1970 年代的编码限制……没人读"沙堆"式代码，因为它本就不是写给人看的。写文学化的程序吧，别再像你爷爷那样编程。
daly查看英文原文
Code is not literature the same way equations are not mathematics. Take any math or physics book, extract all of the equations, and throw away the text. That's how we write programs... just the equations. However, look at Physically Based Rendering (http://www.pbrt.org/). It won an Academy Award. It should win a Pulitzer. All of the actual source code is in the book and the book is quite readable. Or look at Lisp in Small Pieces (https://pages.lip6.fr/Christian.Queinnec/WWW/LiSP.html). There you will find a complete lisp system surrounded by enlightening text. Your confusion stems from the coding constraints of the 1970s. My first machine had 8k of memory, 4k of which was operating system. So programs could not exceed 4k, requiring #include statements. As programs grew they adopt the "pile of sand" (POS) format where the "meaningful" directory names like 'src', 'doc', 'test', etc contain the semantic content. Of course nobody reads POS code. It wasn't written to communicate to humans. It's the late 90s... code like humans matter, like your code needs to be understood, maintained, and modified. Write literate programs similar to Physically Based Rendering and Lisp in Small Pieces. Stop programming like your grandfather did. Oh, yeah, and write provable programs... but that's another rant.
写作和代码都有功利与优美之分，多数只是够用，真正优美的少之又少且需要技艺支撑。
就像写作，有些代码是给人读的，但大多数只是生活的产物。我日常写的邮件、评论、论文、短信，大多不追求美感，偶尔才会写出一点诗意。现实中写作有连续谱：刚撞车时发短信是功利性的；不赶时间但不关心风格，是大多数代码；最后是有意写得优美、希望别人看了说"哇"。但现实是大多数代码和写作都只是功利性的，即使想写得美，也未必有那水平——我想写得像马尔克斯，不代表我能。有堪称文学的代码，但很难找，可能写在白板上就丢了。
owenversteeg查看英文原文
I think, just like writing, some code is meant to be read but most is produced as a fact of life. For example, of what I write in my daily life - emails, HN comments, papers, text messages... the majority aren't meant to be aesthetically pleasing at all. But occasionally I will write something, either on purpose or by accident, that's just a little bit poetic and nice. Or I'll sit down to write a story, or a blog post, or something that's meant to be a bit nicer to read. There's a continuum of how nicely things are written in real life: if you just crashed your car, you might text your family quickly telling them what happened. Or if the site went down, you might hack together a quick fix. That'll be utilitarian, since in a situation like that you don't give a damn about how well the text/code "flows". Then there's writing where you're not pressured for time, but you don't care about the style: most code people write is like this. Then finally there's code, and writing, that's intended to be beautiful. It's written with the intent of showing it to other people, and with the hope that someone will read it and say "wow". The reality, however, is that most code - and most writing - is merely utilitarian. And even when people -do- try to make their code (or writing) beautiful, they aren't skilled enough to do it. Hell, just because I _want_ to write like Márquez doesn't mean I can. There is code that is literature, but it's hard to find. It may be lost, written on a whiteboard in a job interview to impress the company. It may be hidden from the world, the author embarrassed by it. Or, it might be out there somewhere, but nobody's discovered it yet.
读代码不是线性阅读而是主动实验，读者需要动手参与才能真正理解。
Seibel 说读代码更像科学而非文学，完全正确。再可读的代码，面对上万行、众多封装函数，我也得像做实验一样对待，不能像读散文那样线性读。读复杂文学作品可以线性读、偶尔查词；读精心设计的代码却要跟踪多条逻辑流。我学代码靠实验：开调试器单步走、看变量变化、改代码再构建。近年我靠克隆 GitHub 项目并扩展来提升 JS。别只是打开代码库读，要主动参与、破坏、增强。
ideonexus查看英文原文
Seibel's observation that reading code is less like literature and more like science is dead on. No matter how readable the code is, when I'm confronted with 10,000 lines of it spread across numerous encapsulated functions, I must tackle it very differently from how I read prose. With a complex literary text, I can just read it in linear fashion with occasional segueing to look up words and concepts, with well-engineered code I must follow numerous cases into different flows of logic. These aren't the same at all. I appreciate that he's trying to dispel the idea that we "read" code as we read for pleasure, I learn from code by experimenting with it. I open up the debugger and step through it, watch the variables change and see where it goes when I execute it. Most of all, I learn by changing that code and trying to build on it. I have enhanced my javascript skills immensely in recent years by cloning various projects on github and trying to expand on them or adopt them to my own purposes. I don't recommend opening up a code base and just reading it, actively engage it, break it, and enhance it.
同类还值得读
不要想好再写，要写来思考
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 条写作要点编辑精选