[draft] new

1 files changed, 67 insertions, 0 deletions

diff --git a/content/weekly/85.md b/content/weekly/85.md
new file mode 100644
index 00000000..ed2cfedc
--- /dev/null
+++ b/content/weekly/85.md
@@ -0,0 +1,67 @@
++++
+title = "稻草人周刊 Vol."
+subtitle = ""
+tags = []
+date = 2026-06-08T14:37:56+08:00
+draft = true
+toc = true
++++
+
+Blah, blah.
+
+<!--more-->
+
+---
+
+## 止语
+
+{{< music cover="" title="" artist="" apple="" spotify="" netease="" >}}
+
+---
+
+## 连接
+
+### 为 YAML 辩护
+
+> [!note] 📜
+> [In defense of YAML](https://opensource.posit.co/blog/2026-05-21_in-defense-of-yaml/)
+
+文章简单介绍了配置文件格式的历史，从一开始不规范且扁平的 INI 文件，再到能够表达层级但过于臃肿的 XML，之后是适合数据交换但对人类编辑不够友好的 JSON，最终是这篇文章的主角——YAML 和 TOML。
+
+顺带一提，我永远不会错过批评 Java 的机会：
+
+> Anyone who maintained a Java web.xml or an Ant build file in 2003 knows what it was like to edit dozens of nested elements just to change a database connection string. The verbosity made the files difficult to maintain by hand, which is precisely what configuration files demand.
+>
+> 任何在 2003 年维护过 Java web.xml 或者 Ant 构建文件的人都知道，编辑一大堆嵌套的元素，只为了修改数据库连接字符串是什么样的。文件冗长使其很难徒手维护，而这恰恰是配置文件需要的。
+
+如今 Spring Boot 简化了很多配置，但 Java 生态依旧使用 XML 格式，还有另一个令人闻风丧胆的 `properties` 文件，可以说是完美融合了 YAML 和 TOML 两边的**缺点**。
+
+关于 YAML 和 TOML，主流的论调是：TOML 比 YAML 更好，而喜欢用 YAML 的人大多都是不了解情况（uninformed）。YAML 的语法难以预测，比方说 `no` 可能是挪威的国家代码，但会被 YAML 解析为 `false` 布尔值，`off`、`NO` 等其他字符串也是。问题在于 YAML 的隐式类型转换，有无 `""` 都会被视作字符串，大家都习惯不打引号了，而 TOML 必须显式地使用引号才会被解析为字符串。
+
+此外 TOML 还致力于成为标准化的 INI，两者的语法类似，TOML 胜在能用方括号表示层级。尽管语法符合直觉，解析器也很容易实现，但对于深层次的数据结构，TOML 的表现力不如 YAML。如果嵌套较多、列表结构较多，TOML 就会变得很难读。TOML 也因此遭到了批评：
+
+> TOML is a bad file format. It looks good at first glance, and for really really trivial things it is probably good. But once I started using it and the configuration schema became more complex, I found the syntax ugly and hard to read.
+>
+> TOML 是糟糕的文件格式。刚开始看起来很好，对非常、非常简单的事情或许也很好。但一旦我开始使用，并且配置格式变得更复杂之后，我发现语法变得很丑并且很难阅读。
+
+{{< right "——[Martin Vejnár](https://github.com/avakar/pytoml/issues/15#issuecomment-217739462)" >}}
+
+作者在文章最后指出，YAML 1.2 规范解决了以挪威代码为代表的问题，`no`、`yes` 等词不会被解析为布尔值了，只有 `true` 和 `false` 才会。六十进位数被移除了（所以 `22:22` 等端口配置不会出错），时间戳不再是核心类型（`2026-05-05` 会被解析为字符串，而不是自动解析的日期），JSON 是 YAML 的子集了，任何 JSON 文档都可以被 YAML 解析器解析（尽管我想不到这有什么用）。人们认知中问题百出的 YAML 是 1.1 版本，而 1.2 版本已经没有这个问题了。
+
+不过我还是觉得，字符串应该被 `""` 包裹，不应该依赖隐式转换。
+
+支持 YAML 1.2 的解析器较少，所以作者介绍了 [py-yaml12](https://github.com/posit-dev/py-yaml12)，这是用 Rust 写的 Python 库……？
+
+据说是为了与 PyYAML 竞争，这个库是用 C 写的（也有 Python 的实现作为回落方案）。在性能上，由于 py-yaml12 使用编译好的 Rust 程序而不需要解释 Python 程序，性能可以与 PyYAML 竞争，同时它还支持 YAML 1.2，也是目前很难找到替代品的优势。
+
+我的态度是，简单（尤其是层次较浅）的配置文件用 TOML，如果有复杂的配置要求，可以考虑 YAML 1.2。不过，如果配置文件真的足够复杂，用 JavaScript 或者 Lua 等脚本语言作为配置语言，貌似也不错？
+
+---
+
+## 星群
+
+
+---
+
+## 切片
+