"Simple Made Easy" - Rich Hickey (2011)
从这部视频出发 主题阅读 · 1
软件设计测一条业务规则，为什么要连数据库？→字幕解读
Rich Hickey 把简单定义为关注点之间没有纠缠，把容易定义为熟悉、可获得或符合个人能力。他主张评估工具生成的系统，而不只看编写体验；测试、类型系统和模块划分无法替代对依赖的理解。讲座用状态、对象和控制流说明隐含耦合，再讨论值、函数、小抽象、队列和声明式规则如何拆开职责，同时承认资源竞争仍有未解决的复杂性。
英文字幕轨道 · 引文按字幕原文展示，可点时间戳回看片段。
内容要点
- 简单的判断标准是原本能够独立的概念是否被纠缠；熟悉和好上手是另一维度。
- 可变状态把值与时间绑在一起；藏进方法或类里仍可能把这种依赖传给调用方。
- 用小抽象和声明式接口分离要做什么与如何实现，再以队列等机制分开执行时机和位置。
视频章节 6
- 简单与容易
区分结构上的独立与使用者的熟悉程度。
- 从编写体验转向系统产物
说明认知限制、隐含依赖和测试的边界；速度曲线是说明性假设。
- 选择较少纠缠的工具
比较构造的产物，解释为什么模块划分不等于简单。
- 状态、值与替代构造
讨论状态泄漏、不可变值、函数、数据、协议和声明式工具。
- 设计独立的职责
承认环境资源竞争难题，并拆解 what/how/who/when/where/why。
- 保持数据通用与持续简化
避免把数据绑定到表示细节，以可独立变化的部分构成系统。
具体观点与证据 4
评估语言和工具应看它们产生系统的可靠性、可维护性等长期性质，而不只看输入代码是否方便。
区分作者体验与成品复杂性，不否定工具易用性本身。
We have to start assessing our constructs based around the artifacts,类和层次分开不代表系统简单，隐藏语义依赖仍会把模块绑在一起。
模块组织只有结合关注点解耦才有效。
don't associate simplicity with partitioning and stratification, right?把可变实现包在普通方法后并不能隔离状态复杂性，真正稳定的函数式接口才能阻止其向调用者扩散。
允许内部实现可变，要求外部观察满足相同输入相同输出。
a true functional interface, same input, same output.多个组件各自按CPU核数配置线程池，局部合理策略可能在同一进程争夺资源；这类环境复杂性仍未解决。
讲者承认资源政策协调的限制，而非宣称不可变数据解决所有复杂性。
I'll just size my thread pool to be the number of cores.补充字幕原文 2
简单的判断标准是原本能够独立的概念是否被纠缠；熟悉和好上手是另一维度。
start seeing interconnections between things that could be independent可变状态把值与时间绑在一起；藏进方法或类里仍可能把这种依赖传给调用方。
Having state in your program is never simple, right?解读边界
字幕轨道标记为非自动生成，但本次未听音频核对；原字幕仍有拼写和转写问题。 简单/复杂是讲者提出的分析框架，不应转换成经过测量的质量分数。 讲者承认动态性等取舍以及资源竞争问题；不能总结为所有场景都禁用状态。
阅读准备 不需要 Clojure 基础；适合有过维护代码经历的人。
相关视频与证据 7
原则到设计修正形式分层不足以消除语义纠缠
Simple Made Easy警告分开类与层次并不自动带来简单；Maybe Not用schema示例指出把数据形状和调用场景的可选性绑定会造成复用困难，修正需要分离这两个语义维度。
Maybe Not - Rich Hickey ↗
通用聚合定义不应绑定场景可选性。
it's a mistake to put optionality in aggregate definitions▶ 30:36–31:48 · 观看片段"Simple Made Easy" - Rich Hickey (2011)
代码分层本身不等于消除复杂性。
don't associate simplicity with partitioning and stratification, right?适用边界 不主张任何模块拆分都无效；Maybe Not讨论特定信息约束建模。
设计原则的具体化少即是少处理例外与纠缠
API 设计演讲建议不确定时删去不必要内容；Simple Made Easy 将简单解释为关注点不纠缠；两者共同强调减少使用者必须理解的额外选择与依赖。
How To Design A Good API and Why it Matters ↗
API 设计遇到疑问时可删去不必要内容。
When it doubt, leave it out.▶ 24:42–24:45 · 观看片段"Simple Made Easy" - Rich Hickey (2011)
简单指关注点不纠缠，而非仅仅容易上手。
start seeing interconnections between things that could be independent适用边界 删减 API 选项只是一个设计手段；它不自动保证底层关注点已解耦。
机制解释时间模型解释了状态为何造成纠缠
Are We There Yet? 把值定义为不可变快照，并把身份与状态演进拆开；Simple Made Easy 则从理解成本解释可变状态的复杂性。前者提供机制模型，后者给出设计判断框架。这不是两个独立实验相互验证，也不是对状态的全面禁止。
Are We There Yet - Rich Hickey ↗
值是不可变快照；身份是把一系列相关状态联系起来的概念，不能等同于一个原地改变的值。
key characteristic of a value is that it's immutable▶ 24:48–24:53 · 观看片段"Simple Made Easy" - Rich Hickey (2011)
可变状态把值与时间绑在一起；藏进方法或类里仍可能把这种依赖传给调用方。
Having state in your program is never simple, right?适用边界 同一讲者不同层次的设计论述，不是独立实验证实，也不构成立场逆转。
设计应用从状态的时间依赖走向带时间的事实
Simple Made Easy 讨论可变状态的理解负担；The Value of Values 提出保留带时间的事实，避免用当前位置覆盖历史。可把后者当作处理信息历史的具体方向，但它没有证明所有状态都应永久保存，也没有直接给出数据库实现。
"Simple Made Easy" - Rich Hickey (2011)
可变状态把值与时间绑在一起；藏进方法或类里仍可能把这种依赖传给调用方。
Having state in your program is never simple, right?The Value of Values with Rich Hickey ↗
事实包含时间；新的事实替代当前视图，不代表过去的事实变成错误或应被覆盖。
no they don't because facts incorporate time how is▶ 20:30–20:41 · 观看片段适用边界 同一讲者不同层次的设计论述，不是独立实验证实，也不构成立场逆转。
原则落地把可以独立的职责真正拆开
Simple Made Easy 建议辨认原本可独立却被纠缠的部分；Boundaries 将计算核心与命令式外壳分开，是可以用来检验这一原则的具体架构例子。
"Simple Made Easy" - Rich Hickey (2011)
简单的判断标准是原本能够独立的概念是否被纠缠；熟悉和好上手是另一维度。
start seeing interconnections between things that could be independentRuby Conf 12 - Boundaries by Gary Bernhardt ↗
函数式核心外仍需要处理 I/O 的命令式外壳。
an imperative shell that surrounds the functional core.▶ 14:48–14:54 · 观看片段适用边界 这是跨资源分析，不是讲者宣称的继承关系；拆层的价值取决于真实依赖，而不是增加模块数量。
方法补充从识别结构纠缠，退回到审视构思
Simple Made Easy 让我们检查概念之间不必要的关联；Hammock 则提醒许多严重问题源于错误构思。两者把关注点从更快地写出代码移向先理解问题与结构。
"Simple Made Easy" - Rich Hickey (2011)
简单的判断标准是原本能够独立的概念是否被纠缠；熟悉和好上手是另一维度。
start seeing interconnections between things that could be independentHammock Driven Development - Rich Hickey ↗
先处理构思层面的错误，而非只纠正实现。
most of the big problems we have with software are problems of misconception▶ 4:27–4:36 · 观看片段适用边界 两段分别谈系统结构与问题求解，不可把所有构思错误归因为耦合，也不是效率提升的实证证明。
不同视角系统结构与人的理解，是两个维度
一份材料关注产物的结构，另一份关注编程环境如何帮助理解；可用同一个工具作对照。
"Simple Made Easy" - Rich Hickey (2011)
简单的判断标准是原本能够独立的概念是否被纠缠；熟悉和好上手是另一维度。
start seeing interconnections between things that could be independentLearnable Programming ↗
适用边界 两者不是相互反驳，也没有证据表明作者在进行直接辩论。 文章端沿用已有原文导读，本次未重新核验全文；不是双端视频字幕关系。