最近和 AI 写代码很明显的感受是简单性比以往更重要了。当软件的复杂度超出阈值，已经不能在大脑里完成推理的时候，很容易就变得失控，而现在到达失控阈值的速度比以前快多了。刚好翻到这个老演讲 Simple Made Easy，很有收获，下面是Claude的总结：
Simple Made Easy 是 Clojure 语言作者 Rich Hickey 在 2011 年一个著名演讲的标题，核心是区分两个英文词：simple 和 easy，中文都翻译成”简单”，但他认为它们完全不是一回事。
Simple（简单） 指的是客观属性：一个东西不纠缠、不交织，职责单一，没有把多个概念捆在一起。词源是 “sim-plex”——一股、一重。
Easy（容易） 指的是主观感受：上手快、熟悉、就在手边。词源是 “adjacent”——近旁。
他的观点是：人们经常把”用起来容易”误当成”设计上简单”，结果选了一堆 easy 但不 simple 的工具——比如 ORM、复杂框架、共享状态、继承体系。这些东西一开始很顺手，但因为内部把很多概念缠在一起（complect，他自创的词），项目大了之后就变成无法推理的泥潭。
反过来，simple 的东西可能初学时不 easy（比如函数式编程、不可变数据、消息传递），但因为各个概念是解耦的，长期看系统可以保持可理解、可演化。
复杂 Complect 这个词。Hickey 自己挖出来的古英语词，意思是”把本来可以分开的东西编织缠绕在一起”。他用这个词作为判断 simple 与否的唯一标准：看一个构造把多少概念 complect 在了一起。比如 ORM 把对象、关系、持久化、身份缠在一起；锁把值和时间缠在一起；继承把类型、命名空间、多态、实现复用缠在一起。
简单 Simple 是一种选择，不是技能问题。他强调 simple 不需要天才，只需要警觉和纪律——你得不停地问”这两个东西真的必须缠在一起吗？“很多工程师的本能是抓 easy 的工具，因为 deadline 在催，但这是用未来的复杂度换今天的速度。
可靠性来自能推理。他的论点是：测试、类型、调试器都只能发现你想到的问题；只有当系统足够 simple、你能在脑子里推理它时，才能发现你没想到的问题。复杂系统里 bug 是涌现的，再多测试也兜不住。
Easy 是相对的，simple 是绝对的。Easy 取决于谁在用——对一个 Java 老手来说 Spring 很 easy，对新人不是。但 simple 是系统本身的属性，不随观察者变。
Simple Made Easy 是 Clojure 语言作者 Rich Hickey 在 2011 年一个著名演讲的标题，核心是区分两个英文词：simple 和 easy，中文都翻译成”简单”，但他认为它们完全不是一回事。
Simple（简单） 指的是客观属性：一个东西不纠缠、不交织，职责单一，没有把多个概念捆在一起。词源是 “sim-plex”——一股、一重。
Easy（容易） 指的是主观感受：上手快、熟悉、就在手边。词源是 “adjacent”——近旁。
他的观点是：人们经常把”用起来容易”误当成”设计上简单”，结果选了一堆 easy 但不 simple 的工具——比如 ORM、复杂框架、共享状态、继承体系。这些东西一开始很顺手，但因为内部把很多概念缠在一起（complect，他自创的词），项目大了之后就变成无法推理的泥潭。
反过来，simple 的东西可能初学时不 easy（比如函数式编程、不可变数据、消息传递），但因为各个概念是解耦的，长期看系统可以保持可理解、可演化。
复杂 Complect 这个词。Hickey 自己挖出来的古英语词，意思是”把本来可以分开的东西编织缠绕在一起”。他用这个词作为判断 simple 与否的唯一标准：看一个构造把多少概念 complect 在了一起。比如 ORM 把对象、关系、持久化、身份缠在一起；锁把值和时间缠在一起；继承把类型、命名空间、多态、实现复用缠在一起。
简单 Simple 是一种选择，不是技能问题。他强调 simple 不需要天才，只需要警觉和纪律——你得不停地问”这两个东西真的必须缠在一起吗？“很多工程师的本能是抓 easy 的工具，因为 deadline 在催，但这是用未来的复杂度换今天的速度。
可靠性来自能推理。他的论点是：测试、类型、调试器都只能发现你想到的问题；只有当系统足够 simple、你能在脑子里推理它时，才能发现你没想到的问题。复杂系统里 bug 是涌现的，再多测试也兜不住。
Easy 是相对的，simple 是绝对的。Easy 取决于谁在用——对一个 Java 老手来说 Spring 很 easy，对新人不是。但 simple 是系统本身的属性，不随观察者变。
