编程中的实用主义谚语
我原本打算撰写一篇关于“编程中的实用主义”的常规散文文章，但后来决定尝试以谚语风格进行写作。
以下概念体现了我所秉持的哲学观点，我将其称为_编程中的实用主义_。
由Ginger Bill撰写的谚语
编程的概念
- 编程是解决计算机领域中遇到的问题的工具
- 程序的目的是，也应当是，将数据转换为其他形式的数据
- 尝试解决你遇到的具体问题，而不是你可能遇到的通用问题
- 编程语言、编译器、库等只是工具，它们不是世界观，也不是社会地位的象征
问题解决
- 理解你正在编写的程序的目的
- 解决问题需要依次完成四个思维步骤，且不能跳过：
- 目的
- 功能
- 使用
- 实现/形式
- 现实是问题的一部分
- 编程中最困难的部分是理解你试图解决的问题
- 尽量从局部角度思考你的问题
- 一旦你采用通用解决方案，就会失去关于具体情况的信息
- 通用解决方案很少是你真正需要的
- 如果数据发生变化，问题也会随之变化
- 在解决一个多方面的问题时，尽量先解决最常见的情况，而不是最通用的情况
实践
- 大多数情况下无需过多关注程序的实现细节。只要你理解问题的目的、功能和使用方式，实现通常会变得简单
- 没有实践、实验和失败，你就无法成为优秀的程序员
- 不要害怕尝试新工具，但要寻找那些已被证明有用的工具
模型构建
- 要解释任何事物，你都需要一个解释模型
- 试图将你的问题建模为一个世界模型是错误的，因为这是类别错误。你的问题的现实与一个不存在于计算机中的类似事物的现实可能不同。
- 对于任何论点、提案或替代算法，请记住问自己：
- 与什么相比？(有哪些其他想法存在？)
- 你有什么确凿的证据？(经验、实证、定量、定性等)
- 成本是多少？(性能、速度、内存、能源、理智、金钱等)
- 对任何声称能解决所有问题却没有证据或反例的新想法保持怀疑态度
- 你唯一应该关注的是你试图解决的问题
- 困难的问题就是困难的
- 硬件是你试图解决的领域的一部分
- 代码与现实世界之间的相似性并不意味着因果关系
- 模型的价值取决于其预测能力和解释力
- 大多数所谓的“最佳实践”很少有证据支持其主张，尤其是关于其最佳性的主张
- 不同的人会有不同的风格，这些风格对他们来说更具生产力
管理
- 简单性本身就是复杂的
- 清晰胜过巧妙
- 对未来的自己要宽容
- 努力遵循最小惊讶原则
- 让零值有用
- 复制通常比依赖更好
- 错误没什么特别的，把它当作其他代码一样对待
- 记录过程的使用，不要描述签名
- 编译器对你的程序的含义一无所知
- 随着程序规模的扩大，问题也会随之增加
实验与涌现
- 不要害怕扩展一个想法，但要记得在过程中清理你制造的混乱
- 对象是具有关联行为的值，这意味着它们具有自主性
- 对于某些问题，对象会自然产生；不要围绕对象的概念进行设计
- 面向对象编程并非万能良方
- 函数式编程并非万能良方
哲学概念
- 并非所有事物都能通过先验知识得知，可能需要通过实验来发现解决方案和后验真理
- 整体模型很少存在；现实比我们预期的更复杂，无需为特定事物专门设计模型
- 判断某事物是否有用需要利益相关以获取反馈
- 面向对象编程是对亚里士多德形而上学的误解和误用，将其应用于一个它从未被设计用来建模的领域
- 学术计算机科学并非经验科学，而是像数学一样的形式科学
- 学术计算机科学对其宣扬的概念很少有实际利益关联
- 编程是一门相对年轻的技艺，积累的智慧极为有限
- 人们会自然倾向于追逐_短暂潮流_，试图从中寻找智慧；而经过验证的文化实践中蕴含着真正的智慧
- 将行为与数据关联意味着存在能动性，然而这种能动性并非真实存在， merely 数据解释模型的成因
- 许多人无法超越自身所秉持的范式。他们难以超越概念框架，因为他们并未意识到自己是在一个(有缺陷且不完整的)模型中思考，且存在多种解读世界的不同模型。
- 你无法教授美德，只能通过学习获得。向有美德的程序员寻求智慧，并询问他们对美德的看法。
- Bodging 是在必要时使用手头可用的工具和材料完成工作，尽管这种方法未必优雅，但仍然可行。
- 大多数人认为自己在编程时是务实的，但实际上他们通常是在_bodging_。
- 权宜之计的成本极高，不应依赖它。
其他主题
- 如果包的概念定义明确，包管理器就是一个简单的程序。
- Bikeshedding在简单话题中很常见，由知识浅薄的人提出。
- 汇编语言是机器码的直接表示；(简单的)C语言是基于类型理论的汇编语言最简单的表示之一。
名言
亚里士多德
在任何系统性研究(methodos)中，只要存在第一原理、原因或元素，知识与科学便源于对这些要素的认知；因为我们认为自己了解某物，恰恰是因为我们掌握了其首要原因、首要第一原理，直至最基本的元素。因此，在自然科学及其他领域，我们应首先致力于探讨关于第一原理的问题。我们道路的自然方向是从我们更熟悉、更清晰的事物，转向那些本质上更清晰、更熟悉的事物；因为我们所知的事物与那些无条件(haplôs)被知的事物并不相同。因此，我们必须按照这一程序，从那些本质上较不清晰但对我们而言更清晰的事物，逐步转向那些本质上更清晰、更熟悉的事物。
- 《物理学》184a10–21
对于这个主题，我们与其他主题一样，应先呈现各种观点，然后在首先审查这些观点所涉及的困难之后，最终尽可能确立所有或至少大部分以及最重要的关于这些心理状态的普遍观点；因为如果矛盾能够解决，并且当前观点的残余部分得以保留，那么真实观点就已足够确立。
- 《尼各马可伦理学》
然而，我们必须不仅从我们的结论和前提出发，还要从人们对它的普遍看法出发来考虑它；因为与正确观点相符的所有事实都和谐一致，但与错误观点相符的事实很快就会发生冲突。
- 《尼各马可伦理学》
卓越绝非偶然。它总是高尚意图、真诚努力和智慧执行结果；它代表了在众多选择中的明智抉择——选择，而非偶然，决定了你的命运。
- 《尼各马可伦理学》
思考和学习带来的愉悦将使我们更加热衷于思考和学习。
- 《尼各马可伦理学》1153a23
威廉·詹姆斯
许多人以为自己在思考，其实只是在重新排列自己的偏见。
我们所看到的这个看似疯狂的世界，是由于一个不再有效的信念体系所致。要以不同的方式感知世界，我们必须愿意改变自己的信念体系，让过去随风而去，拓展对当下的感知，并消除心中的恐惧。
智慧的艺术在于知道该忽略什么。
Mike Acton
所有程序及其各个部分的目的是将数据从一种形式转换为另一种形式。
不同的问题需要不同的解决方案。
如果你有不同的数据，你就面临不同的问题。
如果你不了解硬件，你就无法评估解决问题的成本。
的一切都是数据问题。包括可用性、维护性、调试性等。一切
解决你可能不存在的问题会带来更多你确实存在的问题。
延迟和吞吐量在顺序系统中是相同的。
经验法则：哪里有一个，哪里就有许多。试着在时间轴上寻找。
经验法则：你拥有的上下文越多，你就能越好地制定解决方案。不要丢弃你需要的数据。
软件并不是在由计算机科学博士的狂热梦想驱动的魔法仙境中运行的。
理性必须占上风，如果任何事情因任何原因而不可理喻，或纯属虚构，那么它就必须被淘汰。
弗雷德·布鲁克斯
给我看你的流程图，隐藏你的表格，我将继续感到困惑。给我看你的表格，我通常不需要你的流程图；它们将显而易见。
- 《人月神话：软件工程随笔》(1975，1995)
回顾过去可以发现，尽管许多优秀且实用的软件系统是由委员会设计并作为多部分项目的一部分构建的，但那些激发了热情粉丝的软件系统，都是由一两个设计者或少数几位杰出设计师的作品。
- 没有银弹
C.A.R 霍尔
语言设计师应熟悉他人设计的多种替代功能，并具备卓越的判断力来选择最佳方案并排除任何相互矛盾的选项……他绝不能做的一件事是纳入自己未经验证的创意。他的任务是整合，而非创新。
程序最重要的特性在于是否实现了用户的意图
艾伦·C·凯
大多数想法都源自之前的想法。
- 小型语言的早期历史
罗布·派克
数据至上。如果你选择了正确的数据结构并合理组织了事物，算法几乎总是显而易见的。数据结构，而非算法，是编程的核心。
规则1：你无法预知程序会在何处耗费时间。瓶颈往往出现在意想不到的地方，因此在未证实瓶颈位置前，切勿试图猜测并添加性能优化代码。
计算领域中，没有任何事物能抵御额外间接层的破坏。
当不存在类型层次结构时，你就无需管理类型层次结构。
复杂算法在 N 较小时运行缓慢，而 N 通常较小。
尼古拉·维特
可靠且透明的程序通常不符合设计者的利益。
- 《数字异议者退休》(1999)
… 我们不认为仅仅因为某种资源便宜就大量消耗它是良好的工程实践。
- 奥伯龙项目
越来越多的人似乎将复杂性解读为 sophistication，这令人费解——难以理解的事物应引起怀疑，而非赞叹。这可能源于一种错误的信念，即使用神秘的设备能赋予用户 [额外] 的力量。
