knowledge-vault/diary/2025/2025-06/2025-06-19.md

7.6 KiB
Raw Permalink Blame History

文科与理科的一个最大差异: 文章写完了可能才是开始写文章需要3小时改可能要画6小时。尤其是诗歌改几个字词要花一年贾岛 代码写完,只要目标实现,这个工作基本实现,程序界有一句话叫,这个代码能跑起来,你就别改。

当然这是夸张的说法,代码有重构的概念,而文章还有交差的,但是总体来说文章与代码是不同的目标。

对于以上,请你用逻辑思维和批判性思维来考虑,

  1. 逻辑是否成立
  2. 有哪些遗漏和补充

Ge

这是一个非常精彩的观察和类比,它触及了文科与理科在思维模式和产出标准上的一个核心差异。我们用逻辑和批判性思维来深入分析一下。

1. 逻辑是否成立?

结论:这个类比的核心逻辑在很大程度上是成立的,但它建立在对两者最典型、也最具艺术/工程色彩的极端案例上。

这个类比的逻辑之所以成立,是因为它准确地抓住了两者在目标、评价体系和“完成”定义上的根本不同。

A. 核心目标的差异 (The Core Logic's Validity)

  • 文章 (尤其是文学作品) 的目标:唤起共鸣、传递情感、引发思考、创造美感。 这是一个主观和开放的目标。一篇文章是否“好”,取决于它在读者心中产生的效果。这种效果没有上限,因此修改和打磨的过程理论上是无限的。贾岛的“推敲”就是为了在“僧推月下门”和“僧敲月下门”之间,选择一个能引发更丰富联想、更具画面感和音韵美的表达。
  • 代码 (尤其是功能性程序) 的目标:解决一个明确的问题、实现一个具体的功能。 这是一个客观和封闭的目标。代码是否“好”,首先取决于它是否能正确、高效地完成预定任务。一旦这个目标达成,它的核心使命就完成了。

B. 评价体系的差异

  • 文章的评价:主观性、多维度。 评价标准包括但不限于:思想深度、情感张力、结构精巧、语言优美、风格独特。这些标准很难量化,不同的读者(评委)会有不同的看法。
  • 代码的评价:客观性、可量化。 评价标准包括:功能正确性 (Passes all tests)、运行效率 (时间/空间复杂度)、健壮性 (能处理异常)、安全性。这些标准大多可以通过测试和工具来验证。

C. “完成”的定义不同

  • 文章的“完成”是相对的。 “写完了”只是草稿完成,进入了新的阶段——修改、润色、升华。对于追求极致的作者来说,作品永远有提升空间。
  • 代码的“完成”是明确的。 “跑起来了”并且通过了所有测试用例意味着一个可交付的、功能完整的版本诞生了。后续工作如重构是提升质量而不是从0到1的创造。

所以,你提出的“文章写完才是开始,代码跑通基本结束”这个核心逻辑,作为一种高度概括的观察,是成立的。


2. 有哪些遗漏和补充?

你的观察非常敏锐,但为了让这个比较更全面、更严谨,我们需要补充一些被这个“夸张说法”所简化的细节。这个类比描绘的是两个领域的“艺术巅峰”与“基础工程”的对比,但现实中两者都存在一个广阔的谱系。

A. 对代码世界的补充:远不止“跑起来就行”

“能跑起来,你就别改”这句话,在专业软件工程领域通常被当作反面教材,它描述的是一种叫**“技术债” (Technical Debt)** 的状态。

  1. 重构 (Refactoring) 的重要性远超你的描述。 它不是锦上添花,而是核心工程实践。糟糕的代码(能跑但难以理解、难以修改)会给未来的维护、扩展和团队协作带来巨大的成本。一个优秀的程序员花在重构、优化代码结构上的时间,可能远超最初写出“能跑”版本的时间。这和作家修改文章的过程非常相似,目标都是为了让作品(代码)更清晰、更优雅、更经得起时间的考验。
  2. 代码也有“文采”和“风格”。 同样实现一个功能好的代码如同一篇结构清晰、用词精准的说明文读起来毫不费力。而差的代码则像一篇逻辑混乱、词不达意的文章。在顶尖程序员眼中代码不仅是工具也追求一种“美感”——简洁之美、逻辑之美、架构之美。Donald Knuth的传世之作就被命名为 The Art of Computer Programming(计算机程序设计的艺术)。
  3. 代码的“受众”是双重的。 代码不仅要让机器读懂(运行),更要让人(其他程序员)读懂。为了“可读性”和“可维护性”所做的努力,和作家为了让读者更好地理解而修改文章,其思维过程是相通的。

B. 对文章世界的补充:并非所有文章都追求“推敲”

贾岛的诗歌是文学创作的顶峰,但并非所有“文科”产出都遵循这个模式。

  1. 功能性写作 (Functional Writing)。 例如,一份产品说明书、一份法律合同、一篇紧急新闻稿。这类文章的首要目标是准确、清晰、无歧义,而不是艺术美感。修改它们的目标是消除漏洞和歧义,这和调试代码以消除 bug 的过程非常相似。在这里,“交差”和“实现功能”是等价的。
  2. 效率优先的写作。 很多时候,文章的产出有严格的时间限制(如记者赶稿、公文写作),目标是“在截止日期前完成一个足够好的版本”,而不是“创作一个传世之作”。这和敏捷开发中的“快速迭代”思想异曲同工。

C. 核心的共同点:抽象、结构与迭代

如果剥去外壳,两者在底层思维上存在深刻的共性:

  1. 抽象与建模: 写文章要先立意、搭框架;写代码要先做系统设计、建数据模型。两者都是将复杂的现实世界或思想抽象为简化的结构。
  2. 逻辑与结构: 一篇好的议论文,其论点、论据、论证过程要求逻辑严密;一个好的程序,其模块划分、函数调用、算法流程也要求逻辑清晰。两者都极度考验结构化思维。
  3. 迭代与优化: 无论是文章的“草稿-修改-定稿”,还是软件的“原型-开发-测试-重构”,核心都是一个不断迭代、追求更优解的过程。

总结与升华

你的观察是一个绝佳的切入点,它用一种生动的方式揭示了文理思维的典型差异。

  • 逻辑成立之处:它准确捕捉了文学创作功能编程终极目标(主观共鸣 vs. 客观实现)和评价标准上的本质区别。
  • 遗漏与补充:现实中,软件工程也包含大量类似修改文章的“美学”和“结构”优化工作(重构、追求代码优雅);而文字工作也包含大量类似编程的“功能性”和“精确性”要求(技术文档、法律文书)。

因此,一个更精确的说法可能是:

文科与理科的差异,不在于“修改”这个行为本身,而在于“修改”所依据的准则。

  • 文章的修改,往往是在一个主观、开放的美学和情感坐标系里,寻找一个更好的“表达点”。
  • 代码的修改(重构),则是在一个客观、约束的逻辑和效率坐标系里,寻找一个更优的“实现点”。

但顶级的作家和顶级的程序员,都在其领域里追求着同一种东西:用最简洁、最优雅、最深刻的方式,构建一个完美的结构来表达思想或实现功能。 在这个层面上,他们殊途同归。