岸边札记 02.2-A｜工程不是许愿池 · No Free Wishes

我曾经在网络上试图向一群孩子解释，为什么他们使用的积木式编程语言很难同时拥有极高的性能与接近底层的控制能力。

他们的疑问其实非常合理：既然图形化编程更简单，那为什么不直接把它做得和底层语言一样快、一样自由，然后让所有人皆大欢喜？

很遗憾的是，正如前文所提到的： “理想总是与现实有点小矛盾，两人并不总是喜欢达成一致。”

更确切地说，图形化本身并不必然导致低性能。 真正的问题在于——面向儿童的编程语言通常希望隐藏内存、线程、类型、资源生命周期与硬件差异，同时提供即时反馈、安全沙箱和近乎不会崩溃的使用体验。
（至于某些项目为了性能使用的“黑魔法”，那又是另一条不太适合儿童误入的支流了。）

可被隐藏的复杂性并不会因此消失，它只是被转移给了语言实现者和运行时。

如果再把底层控制一点点还给用户，性能与自由度或许会上升；但那些原本被隐藏的复杂性，也会顺着同一扇门重新走回来。

后来，当我开始思考匿名网络时，我又遇见了同一个问题。

我们当然希望一个匿名通信系统延迟极低、吞吐量极高、无需中心节点、不依赖可信方、能够抵抗流量分析和女巫攻击（Sybil attack）， 同时还部署简单、价格便宜，并且最好今天下午就能完成，再把 ACM CCS 的最佳论文和 Nature 录用通知塞我怀里，最后去厨房给我炒俩菜。

需求方对此表示：

是的，任何人间奇迹。

遗憾的是，需求清单可以无限延长，带宽、时间和现实世界却没有义务随之扩张。

多增加一次转发，可能增加路径的不确定性，却也增加延迟与失败概率。
加入掩护流量可能遮蔽部分通信模式，却必须支付带宽与能耗。
降低延迟改善了体验，也可能使时序关联更加明显。

因此很显然，所谓 “匿名”，从来不是一个可以单独打开的开关，而是在特定威胁模型与系统条件下才能讨论的性质。

我后来才意识到，我当时真正试图向那些孩子解释的是一个更加普遍的问题：

为什么工程无法同时满足我们的所有愿望？

因为工程是给每个愿望标上代价，而非许愿