笔记 · 04 | 编程语言的进化

本篇要回答的问题：从汇编到今天，编程语言沿着哪条线进化？"面向连接"到底是什么？语言的选择对架构又意味着什么？

上一讲讲了汇编——编程语言的诞生。本讲继续往上，把视野从"语言诞生"拉到"语言进化"。汇编是软件工程师这个分工出现的标志；但若只把编程语言看作一门专业技能，其实低估了它的革命性。

软件是活的书籍

一个升华的观点：软件是活的书籍，是人类知识传承能力的一次伟大进化。书籍能做的，软件都能做且做得更好：

软件强于书籍之处	含义
表达方式多样	不只文字，还有超链接、声音、动画、视频、实时交互反馈
对技术的现场还原	软件本身可以是技术的一部分，传承精确，失传概率大降

由此可预判一个未来：每个小孩的基础教育中一定会有编程教育，就像学物理和数学一样。

编程范式的进化

编程语言只有六十多年历史，迭代却远快于自然语言。从思想表达角度看四种范式：

范式	核心主张	代表语言
过程式	一条条命令执行；核心是结构体 + 过程（函数）	Fortran、C/C++、JS、Go
函数式	变量不可变、函数尽量无副作用 → 错更少、质量更高	Haskell、Erlang
面向对象	引入契约，用对象封装使用界面，不主张全局函数	Java、C#、C++、Go
面向连接	朴素的组合思想——研究代码与代码怎么组合	Go

函数式相对小众：变量不可变意味着改一个数组元素要复制整个数组，得用平衡二叉树重做"数组"——想用它，数据结构这门课得重修。

展开精读：四种范式各自的推理链（过程式为什么核心恰好是「结构体 + 过程」、函数式那两条禁令
为什么能作废整套数据结构、继承凭什么算过度设计、「面向连接」到底在说什么），
见同目录 精读-04-四种编程范式.md。

从"面向对象"到"面向连接"

面向对象的核心是引入契约，基于对象抽象和封装使用界面，两大优点：

优点	含义
清晰的使用界面	某类型有哪些方法一目了然
信息的封装	不主张绕过接口侵入内部实现，提升可复用性

再加上接口，优雅地实现了过程式很费劲才能做到的多态。

但继承被点名为过度设计：它带来编码便捷，也带来"组合还是继承"的心智负担。最完美的答案是 Go 给的——放弃继承，全面强化组合。

Go 自称是面向连接的语言。所谓面向连接就是朴素的组合思想，关键在于：契约不只对象需要，语言设计的方方面面都需要契约：

连接契约	约束了什么	Go 的做法
代码规范	人与人的连接	从语言设计上消灭最易起争议的地方，专注意图表达
消息传递	进程（goroutine）与进程的连接	内建 channel，且类型安全，降低犯错机会

这一节的钥匙是「契约」——原文反复用却没定义。展开见 精读 · 第四部分。

其他方面的进化

除范式外，语言还在工程化能力上进化：包（发布单元）、版本（依赖管理）、文档生成、单元测试。从执行器行为看分三类：

执行方式	代表
编译为可执行程序	Fortran、C/C++、Go
编译为跨平台字节码 + 虚拟机执行	Java、Erlang
直接解释执行	JavaScript（现多数内部仍有字节码虚拟机提性能）

语言对架构的影响是什么？

回到第 01 讲的架构图，简化后用三种颜色表示不同层次依赖：

颜色	依赖层次
淡紫色	硬件依赖——程序工作的物理基础
淡绿色	软件依赖——程序工作的生态环境
桔色	库/源代码依赖——程序本身的组成（框架基础库 + 业务架构）

唯技术论看：业务架构怎么拆模块由业务需求决定，与语言无关，语言只影响模块规格的描述语法（用语言无关接口，还是用开发语言描述——本着"如无必要勿增实体"，作者倾向后者）。

但实践中语言选择极其关键：

影响维度	原因
开发效率	不同语言的社区资源、沉淀的框架与基础库差异巨大
后期维护	语言有生命周期，会走向衰落——选熟悉的还是选面向未来的，是两难

总结

本讲抛开语言发展史，从编程范式演进的角度谈进化：过程式、函数式、面向对象，重点落在 Go 带来的面向连接思想，并与面向对象做了对比。

先把"是什么"回答清楚

概念	一句话说明
软件是活的书籍	知识传承能力的进化——表达更多样、还原更精确
四种范式	过程式 / 函数式 / 面向对象 / 面向连接
面向连接	朴素的组合思想，把契约推广到语言每个角落
继承	过度设计，组合才是复合对象的本道

一句话速记

语言进化的方向是"更接近人的思维 + 更强的契约/组合"；语言与业务架构理论无关，实践中却决定效率与维护成本。

思考题

新范式的出现越来越难，且新思潮容易"用力过猛"（继承就是例子）。要想突破，需要批判性思维。在你熟悉的语言里，有没有某个被奉为"最佳实践"的特性，其实也是一种过度设计？