Maybe Not - Rich Hickey

Rich Hickey 反对在可复用数据 schema 中预先把字段定为必需或可选，因为 optionality 取决于具体使用上下文。稳定 schema 应描述可扩展的数据形状，调用边界再表达需要哪些信息；过早固定约束会妨碍数据演进与组合。Clojure spec 让规格可检验、生成数据并服务于不同边界，同时保留结构演进空间。

自动字幕 · 引文按字幕原文展示，可点时间戳回看片段。

视频章节 6

1. ▶ 0:00
   从 optional 的含义开始
2. ▶ 9:55
   要求与放宽要求
3. ▶ 20:26
   使用上下文决定必需性
4. ▶ 30:13
   数据形状与 schema 演进
5. ▶ 41:29
   边界上的请求规格
6. ▶ 50:10
   规格的范围与组合

具体观点与证据 4

放宽输入要求或增强输出保证在语义上应兼容，但把普通值改装Maybe等包装可能让调用者必须改代码。

针对演讲所比较的包装类型接口，不是否认静态类型检查的作用。

an easing of requirements should be a compatible change

▶ 8:40–9:21 探索此观点 →

字段是否必需取决于使用场景，把可选性固定进通用聚合定义会阻碍schema复用。

函数调用边界可以规定要求；批评的是脱离上下文的统一要求。

it's a mistake to put optionality in aggregate definitions

▶ 30:36–31:48 探索此观点 →

是否需要地址与提供地址时需要哪些字段是两个独立约束，应可分别表达。

嵌套schema需要深入到属性树表达条件。

addresses are optional but if you give me an address you have to give me a whole address

▶ 44:29–44:39 探索此观点 →

调用边界的选择器表达最低信息要求，允许额外字段流经不关心它的处理阶段。

开放式spec设计原则，不是要求安全协议接受任意未知输入。

this is just minimal requirements you can always have more stuff

▶ 47:13–48:07 探索此观点 →

补充字幕原文 2

同一字段是否有用或必需，需要结合消费该数据的上下文判断。

information in a certain context so when

▶ 4:03–4:11

共享 schema 不应仅因某个局部上下文就收紧所有用途的要求。

schemas just because the contexts are

▶ 33:32–33:38

解读边界

这是 Rich Hickey 对数据建模和 Clojure spec 的论证，不是对所有静态类型系统的完整比较；字幕中的部分示例 ASR 有误，且演讲没有量化该方法的工程成本。