思考与写作jsomers.net
一篇三页纸撼动哲学界的论文，及其对软件工程师的启示
A three-page paper that shook philosophy, with lessons for software engineers
2019 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章解读了哲学史上仅三页却影响深远的 Gettier 论文：它用反例动摇了“知识 = 得到辩护的真信念”这一定义。作者把 Gettier 问题类比到软件工程——我们常把碰巧正确的信念当成确凿知识，从而在调试和决策中犯错。
为什么经久不衰：它把一个经典哲学思想实验转化为工程师日常会遇到的认知陷阱，提醒人们区分“碰巧对了”和“真的知道”，这种跨界视角让它多年后仍被反复推荐。
HN 评论精选
文中例子并不符合 Gettier 案例的定义，这种类比会误导人放弃可操作的调试方法
至少就文中呈现的例子来看，这个概念弊大于利。第一个表单自动聚焦的例子根本不是 Gettier 案例：作者既没有真信念，也没有得到辩护的信念——他在提交前 rebase 过，本应知道中间还有别的改动。把这类问题归为 Gettier 问题，等于暗示你无能为力、只能靠直觉；而如果把它看作“没先定位 bug 来源就动手修”，那就有明确的改进办法：花点时间找到并理解 bug，而不是靠猜。
bunderbunder查看英文原文
> A philosopher might say that these aren’t bona fide Gettier cases. True gettiers are rare. But it’s still a useful idea... At least as presented, I see the idea being used to do more harm than good. Take the first example, with the form not autofocusing. We're already not in a Gettier case, because the author didn't have JTB. The belief that he caused the bug obviously wasn't true. But it wasn't justified, either. The fact that he had rebased before committing means that he knew that there were more changes than just what he was working on between the last known state and the one in which he observed the defect. So all he had was a belief - an unjustified, untrue belief. I realize this may sound like an unnecessarily pedantic and harsh criticism, but I think it's actually fairly important in practice. If you frame this as a Gettier problem, you're sort of implying that there's not much you can do to avoid these sorts of snafus, because philosophy. At which point you're on a track toward the ultimate conclusion the author was implying, that you just have to rely on instinct to steer clear of these situations. If you frame it as a failure to isolate the source of the bug before trying to fix it, then there's one simple thing you can do: take a moment to find and understand the bug rather than just making assumptions and trying to debug by guess and check. tl; dr: Never send philosophy when a forehead slap will do.
与其追求绝对确定的知识，不如用概率化的因果推理来指导调试和决策
把心智看作概率化的生存引擎而非真理引擎会更有帮助。田野里出现一头牛，几乎不可能是纸糊的假牛；而草丛里有 50% 概率是蛇你就会逃跑。作者的 bug 确实有较高概率是他引入的，但他本可以通过回溯提交记录来进一步提高这个概率。实践中的因果推理同样是概率性的：通过多个相互关联的实验和因果模型，正确率会不断上升，但永远不要把相关性误当因果。
thewarrior查看英文原文
I think it helps to look at the mind as a probabilistic survival engine than some truth engine. If there appears to be a cow in a random field the odds are extremely low that someone put a papier mache cow there. If there’s something that has 50 % chance of being a snake you panic and run because that’s a 50 % chance of dying. In the case of the authors bug yes the change he introduced had a good probability of being the cause. However he could have increased the probability by going back over commits and confirming that his exact commit introduced the bug. Now the probability goes even higher. But it could still be machine specific a cosmic ray or whatever but the odds are over whelmingly low. In practice causal reasoning also works in a probabilistic fashion. I have a simple model saying that if a planes engine is on then it’s flying. Its a single step probability and so it’s not very accurate in the real world. I do a bunch of experiments and say a plane is flying if the engine is on and air is going over it’s wings faster than a certain speed. Now we have two correlations connected by a causal model that works in many other cases. Hence the probability of it being correct rises. But at the same time we should never mistake direct correlation for causality. But in daily life it’s “good enough”.
用开放式系统框架和原子化的决策隔离来减少不可预测的结果
这是从开放式系统中学到的教训：开放式系统接收定义不明确的输入，接受的未知输入越多，规则就必须越开放。处理结果有四种：已知输入的预期输出（意图）、已知输入的意外输出（缺陷）、未知输入的预期输出（意外收获）、未知输入的意外输出（无意结果）。应对之道是把决策逻辑隔离成彼此独立的原子单元，配合合理的数据结构，以消除无意的结果。
austincheney查看英文原文
This is a lesson learned well from open-ended systems. An open-ended system is one where input is received to process, but the input is not well defined. The more accepted unknown input becomes the more open the system must be in its rules to process it. The results of processing are: * expected output from a known input (intention) * unexpected output from a known input (defect) * expected output from an unknown input (serendipity) * unexpected output from an unknown input (unintentional) For example I maintain a parser and beautifier for many different languages and many different grammars of those languages. In some cases these languages are really multiple languages (or grammars) imposed upon each other and so the application code must recursively switch to different parsing schemes in the middle of the given input. The more decisions you make in your application code the more complex it becomes and predicting complexity is hard. Since you cannot know of every combination of decisions necessary for every combination of input you do your best to impose super-isolation of tiny internal algorithms. This means you attempt to isolate decision criteria into separated atomic units and those separated atomic units must impose their decision criteria without regard for the various other atomic decision units. Provided well reasoned data structures this is less challenging than it sounds. The goal in all of this is to eliminate unintentional results (see forth bullet point above). It is okay to be wrong, as wrong is a subjective quality, provided each of the atomic decision units are each operating correctly. When that is not enough you add further logic to reduce the interference of the various decision units upon each other. In the case of various external factors imposing interference you must ensure your application is isolated and testable apart from those external factors so that when such defects arise you can eliminate as much known criteria as rapidly as possible. You will never be sure your open-ended system works as intended 100% of the time, but with enough test samples you can build confidence against a variety of unknown combinations.
程序员因错误信念会立即付出代价而被迫学会区分信念与现实，但这种能力难以迁移到生活其他领域
把信念误当事实的倾向，软件开发者每天都在挨打：“这么简单的东西怎么不工作？我不是都考虑到了吗？”久而久之你被迫认识到信念不等于现实。但这种洞见很难迁移到其他领域，比如人际关系、政治立场——我们宁愿相信它们基于事实，实际上多半是充满假设的信念。原因可能是错误的信念在编程里会立刻反噬，而在其他领域不会。
stareatgoats查看英文原文
The propensity for mistaking belief for facts certainly take daily hits as a software developer. "How come this simple thing isn't working? I thought of everything didn't I?". After a while you are forced to realize that belief isn't the same as reality. It seems insights like this don't easily translate into other domains though, like relationships, dearly held political views etc. We prefer to think of them as based on facts, when in all probability they are merely beliefs fraught with assumptions. Some people might be good at being skeptics in all areas, but I sense most share my own ineptitude here, the reason probably being that any such (incorrect) beliefs don't immediately come back and bite us, as in programming.
历次讨论
同类还值得读
保持你的身份认同足够小
Keep Your Identity Small (2009)
Paul Graham 2009 年的一篇短文：人一旦把某个话题当成自己身份的一部分（宗教、政治、编程语言皆然），讨论就会退化成站队和争吵，因为此时争论的不再是事实，而是"我是谁…
思考与写作上首页 5 次 · 2009–2021paulgraham.com编辑精选苏格拉底式教学法：通过提问而非讲授来教学
The Socratic Method: Teaching by Asking Instead of by Telling
记录了作者用纯提问的方式，引导一群小学生从零推导出二进制计数法的课堂实验，展示了苏格拉底式教学法的惊人效果。
思考与写作上首页 5 次 · 2011–2022garlikov.com你不能说的话
What You Can't Say (2004)
Paul Graham 2004 年的经典文章，探讨那些因道德时尚而不能公开说出的观点。
思考与写作上首页 5 次 · 2014–2022paulgraham.com编辑精选龙暴君的寓言（2005）
The Fable of the Dragon-Tyrant (2005)
哲学家 Nick Bostrom 于 2005 年写的一则寓言：一条每天吞噬数千人的巨龙（隐喻死亡与衰老）长期被人类当作不可抗拒的自然规律接受，直到有人提出并最终用导弹将其杀死，…
思考与写作上首页 5 次 · 2009–2021nickbostrom.com编辑精选现实有着惊人的细节量
Reality has a surprising amount of detail (2017)
2017 年的博文指出，现实远比我们以为的充满细节：我们习惯用简化的心智模型看世界，直到真正动手做事（比如作者举的造楼梯例子）才发现处处是未曾预料的细节。
思考与写作上首页 4 次 · 2018–2025johnsalvatier.org编辑精选