The Value of Values with Rich Hickey
从这部视频出发 主题阅读 · 1
数据建模用户今天续费了，还能解释昨天那封催缴邮件吗？→字幕解读
Rich Hickey 区分信息的值和存放信息的位置，指出原地更新容易让系统丢失过去。他强调不可变、语义透明的值便于比较、共享、测试与组合，并适合作为跨边界接口。随后把论证推进到事实：事实带有发生时刻，新事实不抹掉旧事实；支持判断的信息系统应保留时间信息，而不是事后从零散日志补回历史。讲座也承认存储回收等代价，重点是信息建模原则，并未给出完整存储实现。
自动字幕 · 引文按字幕原文展示，可点时间戳回看片段。
内容要点
- 不可变与语义透明是本讲重点：值应暴露可理解、可比较的含义，而非依赖隐藏状态。
- 事实包含时间；新的事实替代当前视图，不代表过去的事实变成错误或应被覆盖。
- 值适合作为接口载体：读取者能保有稳定内容，降低跨线程、语言或系统边界传递时的协调负担。
视频章节 6
- 信息为什么变成了可更新的位置
拆解 get/set 式信息观，并以账本和历史存储条件作对照。
- 值的属性与推理收益
讨论可比较性、不可变性、语义透明、共享与测试。
- 从组合到接口
不可变集合保留值的属性；对比传递稳定内容与传递活的位置。
- 事实必须带上时间
事实的过去不被更新抹除，信息系统需要支持跨时刻判断。
- 别靠日志补回丢失的历史
用源码管理和日志反思业务系统的历史信息保存，并解释新事实需要新空间。
- 成本与收束
承认资源成本，重申以信息与事实为中心的系统。
具体观点与证据 4
不可变值支持稳定共享和可重现计算，位置引用则取决于当前位置内容。
函数还需无外部副作用，单靠参数不可变不能保证任意函数确定性。
every time you run that function will you get the same answer no值的组合仍是值，而可变对象的锁策略通常不能随对象组合自动成立。
这是信息表示与协调成本的对比，不是说所有程序都不需要可变状态。
values aggregate to values all the benefits apply to Aggregates信息传输应传递稳定内容，传递存储位置不保证接收者看到同一信息。
讨论位置可变的情形，稳定内容寻址引用属于不同设计。
you can go look at that place and see something totally different事实应包含时间并保留历史，新事实不应抹去曾发生过的事实。
存储回收仍有工程代价，演讲未给出无限保留的具体实现。
you can't update a fact is because you can't change the past补充字幕原文 2
不可变与语义透明是本讲重点：值应暴露可理解、可比较的含义，而非依赖隐藏状态。
values are immutable right and values are semantically transparent事实包含时间；新的事实替代当前视图，不代表过去的事实变成错误或应被覆盖。
no they don't because facts incorporate time how is解读边界
自动英语字幕未做音频核验；开头把事实说成 get/set 位置是反讽，随后明确否定。 不可变数据有利于可重复测试，但仅有不可变输入并不能保证任意计算都是纯函数。 保留事实是设计主张，没有完整定义纠错、保留期限、成本策略或事实真实性验证机制。
多个视频共同讨论的观点
局部对象各自加锁，不保证组合起来仍然安全 →这里讨论共享可变状态的协调成本，并未断言所有锁或所有对象设计都有错。用值表示某一时刻的信息，可以在后续变化发生后保留原来的观察 →一个来源讨论带时间的事实，另一个解释怎样共享结构以保存旧快照；持久化结构并不会自动记录业务时间。阅读准备 建议先了解状态与值的区别。
相关视频与证据 4
数据模型原则到实现问题查询模型之外，还要决定是否保留事实的时间
DynamoDB 讲解要求先枚举访问模式，再按查询组织单表、索引和事务；Hickey 则强调事实包含时间，新事实不应让过去的事实变成错误或消失。连接这两点可以把存储设计从“怎样高效读当前实体”推进到“是否需要表达历史事实”，提示读者将时间与访问模式一并纳入建模。
AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401) ↗
DynamoDB 表结构应围绕应用必须支持的访问模式设计。
understand every access pattern I need to know▶ 27:59–28:05 · 观看片段The Value of Values with Rich Hickey
事实带有时间，新事实可以更新当前视图，但不应抹去旧事实的真实性。
no they don't because facts incorporate time how is适用边界 DynamoDB 演讲中的版本控制例子并不等同于完整的事件溯源或历史事实模型；Hickey 的主张是信息建模原则，不是具体数据库实现指南。
概念扩展从不可变快照扩展到信息值的设计
两者都明确把不可变性作为值的属性；The Value of Values 进一步突出语义透明、比较与跨边界共享。适用层次由进程内时间模型延伸到信息表达，而非立场改变。
Are We There Yet - Rich Hickey ↗
值是不可变快照；身份是把一系列相关状态联系起来的概念，不能等同于一个原地改变的值。
key characteristic of a value is that it's immutable▶ 24:48–24:53 · 观看片段The Value of Values with Rich Hickey
不可变与语义透明是本讲重点：值应暴露可理解、可比较的含义，而非依赖隐藏状态。
values are immutable right and values are semantically transparent适用边界 同一讲者不同层次的设计论述，不是独立实验证实，也不构成立场逆转。
设计应用从状态的时间依赖走向带时间的事实
Simple Made Easy 讨论可变状态的理解负担；The Value of Values 提出保留带时间的事实，避免用当前位置覆盖历史。可把后者当作处理信息历史的具体方向，但它没有证明所有状态都应永久保存，也没有直接给出数据库实现。
"Simple Made Easy" - Rich Hickey (2011) ↗
可变状态把值与时间绑在一起；藏进方法或类里仍可能把这种依赖传给调用方。
Having state in your program is never simple, right?▶ 36:01–36:08 · 观看片段The Value of Values with Rich Hickey
事实包含时间；新的事实替代当前视图，不代表过去的事实变成错误或应被覆盖。
no they don't because facts incorporate time how is适用边界 同一讲者不同层次的设计论述，不是独立实验证实，也不构成立场逆转。
设计应用值的语义，如何落实为模块边界？
Hickey 强调不可变和语义透明；Bernhardt 展示以值作为交互边界，减少同步方法调用及测试替身的耦合。前者解释值的性质，后者给出组织代码的具体策略。
The Value of Values with Rich Hickey
不可变与语义透明是本讲重点：值应暴露可理解、可比较的含义，而非依赖隐藏状态。
values are immutable right and values are semantically transparentRuby Conf 12 - Boundaries by Gary Bernhardt ↗
以值代替同步方法调用作为交互边界。
we now have values as boundaries.▶ 10:17–10:24 · 观看片段适用边界 值并不自动保证整个系统纯函数化；I/O 仍留在外壳。两位讲者没有在这些片段中直接互相回应。