我明白这个观点，但我很好奇为什么人们会觉得这篇文章有吸引力。对我来说，它很薄弱……它建立在一个特定的技术区别上，即“解析”和“验证”，（1）这个区别并不广为人知，也不一致接受，（2）文章中并没有明确说明！（验证：检查数据假设，如果不满足则失败；解析：检查数据假设，如果不满足则失败，并且在成功时返回一个新类型的数据，该类型反映了数据的额外约束，因此可以在编译时进行检查。请注意，解析包括验证，这使得文章的标题非常糟糕。）这一点很重要，因为这种区别只在某些语言特性背景下才有意义，而这些特性可能适用也可能不适用。此外，这并不是很好的通用建议： > 尽可能将证明的责任向上推，但不要过头。 首先，这句话基本上是无意义的，因为它只是说将证明的责任放在正确的位置。但它暗示了“向上”是更优的。…
源讨论解析，而不是验证（2019）原帖 219 条评论 · 导入时统计把你的经验，加入这段讨论。
> 如果这是一个高层次的问题，你真的想把它往上推；如果是低层次的问题，你就要往下推。例如，假设你正在开发一个访问数据库的应用或服务，那么数据库就是低层次的。你希望将特定于数据库的类型转换尽可能靠近访问数据库的代码。 我认为数据库代码和网络代码或文件系统代码处于同一层次的问题。所谓‘往上推’，她的意思是将解析操作推到程序的边界——尽可能靠近输入点。
完整原文> 它建立在一个特定的技术区别之上，即解析和验证之间的区别，(1) 这个区别并不常被理解或一致接受，(2) 文章中并没有明确说明！ 如果你不清楚这一点，问问自己为什么编程语言是被解析的，而不是仅仅被验证的。验证是解析的一个子集，显然还有更重要的东西被添加进来了。
完整原文我从标题就以为在评论里会得到更好的解释，而我确实得到了，但我觉得这篇文章并没有点击标题所暗示的那么糟糕。这是一篇关于如何使用类型来简化代码的不错介绍，而你对数据的了解应该反映在类型上的基本理念非常强大。如果你费心检查数据是否满足某些约束，那么之后你应该能够用更受约束的类型来表示它，这就是解析的本质。这一切都很合理！就连标题也说得通，作为在学习之后快速参考和记忆这个概念的一种方式。 但话说回来，点击标题确实让我有些反感，你所说的术语是有害的，因为解析和验证之间的区别在实际工作中并没有被 consistently（一贯地）区分。我见过的几乎所有“验证”代码都…
完整原文> (2) 其实文章中并没有明确说明！ 验证和解析之间的区别几乎完全在于信息如何被保留。考虑以下两个函数： validateNonEmpty :: [a] -> IO () parseNonEmpty :: [a] -> IO (NonEmpty a) 这两个函数检查的是相同的内容，但 parseNonEmpty 会将它所了解的信息提供给调用者，而 validateNonEmpty 只是将其丢弃。
完整原文> 如果这是一个高层问题，你真的想把它往上推，如果是低层问题，就往下推。例如，假设你正在开发一个访问数据库的应用或服务，那么数据库是低层的。你希望将特定于数据库的类型转换尽可能靠近访问数据库的代码。 我认为这种混淆只是对系统架构不同概念的问题。 你的术语来自于三层架构[0]，包括表示层、逻辑层和数据层。在这种模型下，输入（数据）是底层，输出（HTTP/GUI）是顶层，你的应用逻辑在中间。 另一方面，她则是通过类似六边形架构[1]的内外视角来看待系统。所有的输入（数据）和输出（HTTP/GUI）都被视为在你的应用逻辑之外。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。