漫谈计算机哲学

这篇文章是有人向我提问: "如何避免陷入技术陷阱?作为工程师,我们接触一门新技术,到底要了解到什么程度才能算真正"了解","有深度"。仅仅是会用?了解原理?源码级别二开还是直接打造一款更好的?(给陷入瓶颈的朋友们一点指引)"

当时记得问我计算机哲学来着，随便写了写。

首先让我们忽略上下文单独来讨论计算机哲学这个名词，首先让我们分解这个词计算机哲学，这个词由哲学和计算机组成，计算机是一个范围的限制，就像是贵州人一样，人是一个更加大的涵盖，我们也可以认为名词是一种分类，被划在相同分类的事物一般具备相同的性质，比如我们一般认为云贵川渝的人比较能吃辣。现在让我们来考察哲学，哲这个字在中文里面有两个含义一个是形容词: "聪明有智慧" ，另一个是名词，一个常见的用法是哲人，先哲。这样组合起来看哲学也就是研究智慧的科学，或者我们不妨说是研究思想的科学。

在英文里面哲学对应的单词是Philosophy，是对关于存在、理性、知识、价值、心灵和语言等一般和基本问题的研究。在古希腊语中意为对智慧的热爱。那么这么看来东西方共同认为哲学是一门关于智慧的学科，那什么是智慧? 日常生活中我们经常会称赞某某非常有智慧，在汉语中对应的语义为辨析判断、发明创造的能力。这看起来直观了一下，我们还可以将词汇接着往下解释下去，也许最终会互相解释，也许最终会分解到非常直观的名词，也就是不能再分解的地步。我们依赖的某些理论最终要下沉到不可解释之物，不可分解的理论上。

你一定想到了数学的公理化上，数学的理论大厦最终都依赖于几条不可证明的公理，在这几条公理的基础上建立起庞大而又壮观的数学大厦，数学大厦上上层出现的问题，有时候让人不敢相信的是需要调整整个数学大厦依赖的公理。而哲学是一个非常宽广的领域，粗略的说我们可以分为两类，一类面向人类自身，一类面向社会。面向社会你一定耳熟能详，也就是马克思社会主义哲学。而面向人类自身的可以分为形而上学、认识论、伦理、逻辑。从广义上来说哲学是人们寻求理解关于他们自己、他们所生活的世界以及他们与世界和彼此之间的关系的基本真理时所进行的活动。作为一门学科，哲学也是如此。那些研究哲学的人总是不断地提出、回答和争论生活中最基本问题的答案。

有了对哲学的大致了解之后，我们开始理解计算机哲学，计算机前面限定了讨论的范围，就像贵州人的贵州是对这个词的限制一样，我们来考察这个概念，计算机哲学究竟在考察些什么问题，首先是工程化的问题，工程化来源于1960年的的会议，所谓工程化我们可以认为是要求好维护的，规范化的、可复用的。

当Brooks在《人月神话》中写下没有银弹时，他预见了软件工程的根本困境: 我们试图用分工协作对抗复杂度，却不得不背负历史决策的十字架。那些被抱怨的祖传代码，恰似敦煌藏经洞的卷轴-看似残缺晦涩，却封印着初代架构师与业务需求的的惨烈博弈。真正的技术深度，往往始于对包袱的考古学式解构。

由此引出了软件工程的一些设计，也就是我们常常讨论的高内聚低耦合，面向对象等等。再接着就是如何接受之前的遗产，就像19世纪的伦敦下水道，最初只为百万人口设计，如今却要承载千万级需求。优秀的工程师如同城市改造者，既不能全盘推翻，也不能放任腐锈蔓延。优秀的软件架构师，实则是数字空间的简·雅各布斯。他们深谙《美国大城市的死与生》中的智慧：那些看似混乱的祖传代码街区，往往蕴含着自组织的生命力。真正的重构不是推土机式拆迁，而是像高线公园改造——用最小干预激活生态多样性。每个微服务模块都应是功能混合的街区，在版本迭代中自然生长出API小巷与数据广场

你知道曾经的英特尔试图完全不兼容之前的指令集，这失败了，在软件行业如何不和过去分裂是一个常见的话题，很多时候我们称过去的代码为历史包袱。但我想说包袱的另一个名字叫资产，继承发展才是一个正确的决策。但从新开启一个项目的诱惑力又比较大，许多人都热衷于做一个新项目，在计算机领域有时候面临的一个共有问题，就是在一定的限制下解决问题，这会很有趣，很多时候预算充足的情况下，不需要考虑太多问题，但那会让问题变得无趣起来。

工程化的另外一个问题是工期，科学研究可以一直探索下去，但工程不能允许，我们需要知道工程的工期，在一定的时间里面完成我们的工程，不少程序员会对质量有所要求，但高质量的另一重代价就是时间，我们不可忽视的另一点就是软件工程的软，这意味着可调整性。就像一座城市一样，随着人口的涌入，城市在不断的适应，但是过早规划会浪费很多资金，你也没办法预知你的城市会涌入多少人口，你一定听过那句话，过早优化是万恶之源。上面我所描述的软件更接近于服务于人，虽然软件都是服务于人的，比如你用软件打了车，这种软件是在人和车之间建立连接。 另一类软件是医疗软件，化疗使用的，这类软件所面临的问题很致命，一旦出错就会有很大的代价，这类软件我没有经历过，不做过多评价。

但对于打车这类软件，外界的输入始终是一个不可确定的量，这也是程序会出现bug的原因之一，面向人使用的程序你总无法确定用户是如何使用你的程序的。大部分在人与人之间建立连接的软件抖音、微信，都面临的一个问题就是无法确认产品最终的形态。所以Unix的编程哲学到现在还会经久不衰, 在Unix世界里面，有一个非常明确的悠久传统: 先求运行，再精雕细琢。优化之前先确保能用。这些话的实质也就是，先给你的设计做个未优化的、运行缓慢但很耗内存的正确实现，然后进行系统地调整，寻找那些可以通过牺牲最小的简洁性而获得较大性能提升的地方。

Unix编程哲学的另一个原则是控制复杂度，不要让你的软件太复杂，明确软件的功能这很重要。但对于一个工程师来说，控制复杂度需要一年又一年的练习，才能慢慢体会。最后一个我想告知的Unix的编程哲学原则是排错容易，排错占据开发大部分的时间。

在上面的讨论中我狡猾的先明确哲学本身，然后再缩小范围计算机哲学，事实上计算机哲学这个问题范围也太大了，我接着将问题范围进行缩小，缩小到计算机工程要回答的问题，我们可以粗略的说，所谓的哲学就是在不断的提出问题，不断的解答。然后我们接着对这个问题进行解答，最后引入到该如何编写代码。现在我来尝试你提出的问题，我已经回答了如何理解计算机哲学，并演示了如何考察概念分析问题。 你的第二个问题是对非专业人士生活和思考帮助的小知识，比如去中心化、局部性原理。这些小知识并不独属于计算机。

关于道，其实还是思维的问题，在这一点我已经讨论了很多次了，人类基本的思维方式只有聊聊几种，演绎、归纳、类比。所谓演绎就是从最基础的规则入手，向前推导得出我们想要的结论，归纳从多个个别事物中获取普遍的规则，类比是从两个事物之间具备共性。指由一类事物所具有的某种属性,可以推测与其类似的事物也应具有这种属性的推理方法。这是最基础的道。不仅仅局限去计算机，如果还要提升一点的话，恐怕就是观察结构了，所谓的结构指的就是组成元素和联系，碳和钻石因为结构而表现出来不同的性质，日常中学会分解某项技术由哪几个核心思想组成，然后他们之间的联系是什么，如果你要分解它结构的习惯，会发现大部分框架技术的思想其实是雷同的。就先回答到这里。

最后一个问题:

如何避免陷入技术陷阱?作为工程师,我们接触一门新技术,到底要了解到什么程度才能算真正"了解","有深度"。仅仅是会用?了解原理?源码级别二开
还是直接打造一款更好的?(给陷入瓶颈的朋友们一点指引)

首先是会熟练使用，在熟练使用的时候已经对基本架构和特点有了毕竟深的了解，然后去看源码，看源码的时候也需要关注结构，比如存储结构、使用场景，常常是根据使用场景来引入对应的存储结构和设计。 注意看源码和实践是必要的，理论脱离实践就会变成空中楼阁，所谓的实践就是尝试构造一个新技术的迷你版，当你开始构建，就会有一堆为什么，然后理论就能结合实践，获得更深的体会。

写在后面

校对这篇技术文章的时候发现已经忘记向我提问的人， 提出的技术陷阱是什么意思了，向R1提问, R1给出了几段话:

维纳在《控制论》中揭示：『有效行为必须由某种反馈过程提供信息。』避免技术陷阱的关键，在于建立认知反馈回路——当我们在源码丛林中追逐新技术时，要持续聆听两个声音：来自业务需求的现实回响，与来自哲学原点的元思考

感谢R1向我提供的几个例子:

1. 19世纪的伦敦下水道的改造，这是一个经典的历史包袱距离
2. 美国大城市的死与生相关的论述，也是我将文章丢给大模型，大模型给的论述。
3. 敦煌的例子也来自R1