文章探讨了人们在软件开发和生活中过于自信的问题，指出不确定性是现实的一部分。作者通过GPS坐标的示例说明，代码中的布尔值无法准确反映现实中的不确定性，强调了在编程中捕捉和表达不确定性的重要性。文章呼吁在设计和开发中选择更合适的抽象方式，以更好地处理复杂和模糊的现实情况。

标题：不确定性编程：Uncertain的应用与思考

主要内容：

在软件开发中，人们往往过于自信，倾向于给出明确的答案，而不是承认不确定性。然而，现实世界中的许多问题，如GPS定位，本质上是概率性的，无法用简单的布尔值（true或false）来准确描述。为了应对这种不确定性，2014年华盛顿大学和微软研究院的研究人员提出了一种新的编程范式：将不确定性直接编码到类型系统中，称为Uncertain<T>。

Uncertain<T>是一种概率编程方法，它允许开发者在代码中明确处理不确定性。例如，在比较两个Uncertain值时，结果不是一个确定的布尔值，而是一个表示概率的Uncertain<Bool>。这种方法不仅数学上严谨，而且在实际应用中也非常实用。

通过Uncertain<T>，开发者可以构建计算图，仅在需要具体结果时进行采样。库使用序贯概率比检验（SPRT）来高效确定所需的样本数量，从而在简单比较中可能只需要几十次采样，而在复杂计算中自动扩展。

应用场景：

1. GPS定位：GPS坐标本身是噪声的、近似的，使用Uncertain<T>可以更好地处理定位的不确定性。
2. 运动速度计算：通过Uncertain<Double>类型，可以计算跑步速度等不确定的物理量。
3. 用户行为建模：例如，用户点击按钮的概率可以用Uncertain.bernoulli来建模。
4. 网络延迟：使用Uncertain.exponential可以模拟具有长尾分布的网络延迟。

统计操作：

Uncertain<T>提供了丰富的统计操作，包括基本统计量（如期望值、标准差）、置信区间、分布形状分析（如偏度、峰度）以及累积概率计算等。这些统计量通过采样计算，开发者可以根据需要在计算时间和准确性之间进行权衡。

实践建议：

1. 逐步迁移：可以逐步将关键路径中的计算迁移到Uncertain<T>，而不是一次性重写所有代码。
2. 性能考量：采样是有成本的，开发者应理解计算开销，根据需求选择合适的采样数量。
3. 处理不确定性：目标不是消除不确定性，而是承认它的存在并优雅地处理它。

总结：

在现实世界中，不确定性无处不在。通过Uncertain<T>这样的工具，开发者可以更好地处理不确定性，编写出更智能、更健壮的代码。正如Alan Kay所说：“观点值80个智商点。” 承认并处理不确定性，或许是我们停止假装一切确定性的第一步。

评论内容主要围绕以下几个方面展开：

1. 对库的认可与期待

   • 评论1（mackross）表示对作者的认可：“Always enjoy mattt’s work. Looks like a great library.”（“一直喜欢mattt的作品，看起来是个很棒的库。”）
   • 评论9（black_knight）提到与经典函数式编程文献的关联：“This seems closely related to this classic Functional Pearl.”（“这似乎与经典的函数式编程文献密切相关。”）

2. 对功能扩展的建议

   • 评论2（boscillator）提出处理变量间协方差的需求：“Does this handle covariance between different variables?”（“它能处理不同变量之间的协方差吗？”）
   • 评论7（8note）建议引入方向性误差处理：“id expect something like 'are we there yet' referencing GPS should understand the direction of the error.”（“我希望像‘我们到了吗’这样的GPS引用能理解误差的方向。”）

3. 对技术细节的讨论

   • 评论3（AlotOfReading）指出GPS不确定性模型的复杂性：“GPS is only well-approximated by a circular uncertainty in specific conditions.”（“GPS的不确定性仅在特定条件下才能用圆形模型近似。”）
   • 评论8（cb321）提到误差传播的简化方法：“there is an error propagation simplification for 'small' errors thing you can do.”（“对于‘小’误差，有一种误差传播的简化方法。”）

4. 对编程范式的类比与扩展

   • 评论5（munchler）将其与模糊逻辑类比：“Is this essentially a programmatic version of fuzzy logic?”（“这本质上是不是模糊逻辑的程序化版本？”）
   • 评论6（krukah）从范畴论角度进行类比：“Monads are really undefeated. This particular application feels to me akin to wavefunction evolution.”（“单子确实无可匹敌，这个应用让我感觉类似于波函数演化。”）

5. 对默认不确定性的建议

   • 评论4（layer8）提出默认不确定性的观点：“Arguably Uncertain should be the default, and you should have to annotate a type as certain T when you are really certain.”（“可以说，不确定性应该是默认的，只有在真正确定时才需要将类型标注为certain T。”）

6. 对其他语言实现的探讨

   • 评论10（droideqa）询问是否可以在Rust或Clojure中实现：“Could this be implemented in Rust or Clojure?”（“这能在Rust或Clojure中实现吗？”）

总结：评论者对库的功能表示认可，并提出了扩展功能、改进技术细节的建议，同时从编程范式和语言实现的角度进行了类比与探讨。