单一版本看看就算了，然而升级多出来的不爽的细碎的东西一箩筐，让人觉得产品脑子是不是有坑……
比如没事改截图体验。。。误操作一丢丢。这个可能还不是华为的锅，但少设置项应该跑不掉（我试过三星之类的别的 Android 机默认能改）—— UI 外最明显地，截图格式若干年以前默认 png 的，有人在花粉论坛抱怨怎么不是 jpg （ mdzz ），后来改 jpg 了；过一段时间又另外有人抱怨 jpg 有损，应该 png （看了下确实不是 JPEG2000 ），没回音……我说加个选项让用户自己改会死吗？
再举个例子，原来图片默认浏览好好的按日期分类很明白，突然就给整没了。。。
还好之前有解锁，现在打算继续刷机折腾了。

@Qiaogui 坑太大，不太值。
因为需要 trial & error 成本太大，我回避从头开始造字节码的设计，对这方面了解不够 。

@svenFeng 不合理。
1.你忽略了 phase 可以允许让用户指定的设计。保证停机最终是用户的责任。
另外，做编译器基本上不会是实现语言的直接的目的，所以可以反过来想：“能停机的实现的一部分才叫编译器”。停不下来嘛就凉拌。
2.你忽略了 static 之间也不完全是一回事。
（虽然如果不忽略继续头铁 static 的话可能会进另一个坑，比如 static_assert 大战#ifdef。只是这通常没有 std::integral_constant 和 integral type 没法合并的问题这样恶劣罢了。）

@easylee 你漏了传统 OJ 最原始的用途：举办竞赛和选拔、训练竞赛人员的需要。

现在的话…… zz 正确。

> 我没明白什么是 phasing - -'''

cf. The Definition of Standard ML
Chapter 1, para. 3, 4.

> 这两种双向转换说不上哪个好那个差吧

这显然有问题的。首先转换相比之下是凭空多出来的步骤，如果是兼容历史遗留问题还能理解，对新的项目有什么积极意义？
然后更严重的问题是 spec 本身。
你提的语言里要么默认了，要么明确指出这种和我要求的相反的做法，如 SML 这种为了 formal spec 偷懒，撑死只允许实现混淆 static 和 dynamic phase，而 spec 里是写死了的。但这种 formal spec 的东西其实是没法直接用于不区分 phase 的实现的，实际上变相歧视了更自由的实现（类似 C/C++都明确回避要求编译，但不 AOT 编译实现起来就是吃亏）。
同时，这样 formal spec 更复杂了，而不是标榜的简单了——所谓的简单，是作者自认为的写起来的简单而不是统计写出来东西有多少能客观度量的复杂度的意义上的简单，本质上就是无视元语言的复杂度的鸵鸟政策罢了，就像 AOT 编译把调用编译器的 penalty 无视以后自以为比 JIT 高效一样（ AOT 性能的问题还就是 phasing 破事的另一个具体例子）。
你感觉不出这个问题，可能是因为你和大多数用户一样只使用到现有资源的某一小个子集。比如你用 C，不理解 LLVM 和 cfe 的实现以及 ISO C 的 rules 有多蛋疼，也不是不能干活。但对想要把 spec 垂直地复用到实现上游和下游各个层次、去除其中的重复冗余的 hacker 来说，这是显然不够的。
现在的业界被动适应的这个问题并不光彩，大体思路就是算力不够堆机器，人力不够 996。这是不可持续发展的，同时分工过头导致几乎禁绝垂直复用。虽然能多搞点就业多吹 GDP 吧……

@psychoo 你 at 的这人的 ID 是不是大爷啊，at 一下就要验证手机号。。。

不给修大概是因为修不好。
M$的 SB 也是只换不修，因为太难拆。

哦不对，是 Server Not Found ……

v2ex plus 的选项在我魔改的 Basilisk 里还点不动，点回复还会跳转到 “.v2ex.com/t ” 然后 404。。。手动狗头……

别通胀出来的就好。

@chen2019 污染 commit history 可能引起更严重的强迫症。
（我最烦的是 autocrlf 之类一时半会儿还未必马上能发现的……）

KPI 掌嘴。

@svenFeng 关于定理证明你说得没错，因为定理证明本来就是一个相当 specific 的 domain。
问题在于，从 DSL 里 extract 出 general-purpose language 的做法，比反过来用 general-purpose language 去 derive 不同 DSL 的做法凭空多出不可忽视的工作量，却没有多少现实收益。
后者的做法先不算 derive （因为习惯上只有反过来接着 extract ），在这个 domain 里也就 ML 勉强能算。但是 ML 的问题嘛上面说过了，再加自身扩展起来也很疼，改 spec 不容易，加新 feature 照样得考虑大坨具体 feature 之间的关系，跟真实的 general-purpose 差远了……

@svenFeng 换句话说，没很具体的问题域，一般本来就根本不应该存在全局意义上的 static 不 static，非得预设 static 和不 static 两类性质已经一定程度放弃了能做的不少必要的事情了，有这种 feature 就通用不到哪去。

@svenFeng 当要把一长坨 spec 当代码来维护的时候，就会容易发现一些尴尬的问题，比如缺少 ad-hoc 的特例规则就没法 late binding，需要单独的 reflection 并且要有很多幺蛾子才能实现对，static 和不 static 的类似废话不得不重复，pattern sublanguage 之类的马甲越来越多并且设计上难以去重……所有这类关于可修改性的问题根本都来源于不切实际的 static phasing 的设计。这根本上就是需求理解偏差：通用意义上真正需要的只是保证有限的局部依赖来确定语言的解释的局部有序关系——例如根据某一类特定的计算决定另一类的求值结果，而不是非得具体到预设一坨全局特性集合然后映射到不相交集合甚至干脆直接分层映射到一坨序数上去。后者本质上是一种对实现细节的抽象泄露，一定程度违反了最小特权原则。

@zhuangzhuang1988
另外，你真的敢光看声明不看一坨 dw 之类的 flags 什么意思么……你敢背得清楚 MSDN 里对某个 flags 组合的可用性和版本要求么……

（反过来小声 bb：你敢保证 MSDN 没 bug 么……）（顺便当年随便看 ucrt 源码都能发现 errno 错误码映射错的……）

还有，GetVersionEx 为什么被 deprecated 然后用一坨 zz 接替了，这个逻辑你能解释一下么……