解决停顿问题比人们想象的容易吗？

Question

虽然一般情况不明确，但许多人仍然能够解决日常使用中相当不足的问题。

在科恩关于计算机病毒的博士论文中，他展示了病毒扫描如何与停止问题等效，但我们有一整个行业都围绕着这一挑战。

我也看过微软的终结者项目 - http://research.microsoft.com/Terminator/

这引出了我的问题 - 是否存在被忽视的问题 - 我们是否需要担心一般情况？

随着时间的推移，类型是否会变得完整 - 依赖类型似乎是一个很好的发展？

或者，从另一方面来看，我们是否会开始使用非图灵完整语言来获得静态分析的好处？

Answer 1

  

解决暂停问题比人们想象的容易吗？

我认为这与人们的想法一样困难。

  

随着时间的推移，类型会变得完整吗？

My dear, they already are!

  

依赖类型看起来似乎是一个很好的发展？

非常。

我认为非图灵完全可证明的语言可能会有所增长。很长一段时间，SQL都在这个类别中（它不再是），但这并没有真正削弱它的实用性。我认为，这样的系统肯定有一席之地。

Answer 2

哇，这是一个混乱的问题。

第一：停止问题在实际意义上不是“问题”，如“需要解决的问题”。它是关于数学本质的陈述，类似于哥德尔的不完备性定理。

第二：构建完美的病毒扫描程序是难以处理的事实（由于它等同于停机问题）正是“整个行业围绕这一挑战而建立的原因”。如果可以设计出完美病毒扫描的算法，那么只需要有人做一次，然后就不再需要一个行业了。故事结束。

第三：使用图灵完整语言并没有消除“静态分析的好处” - 它仅仅意味着静态分析存在限制。没关系 - 无论如何，几乎所有事情都有限制。

最后：如果停止问题可以以任何方式“解决”，它肯定会“比人们想象的更容易”，因为图灵证明它是无法解决的。从数学的角度来看，一般情况是唯一相关的案例。具体案例是工程问题。

Answer 3

有很多程序可以解决暂停问题，而且很多程序都很有用。

如果你有一个编译器告诉你“停止”，“不停止”或“不知道”那么它可以告诉你程序的哪个部分导致“停止”或“不要知道“情况。如果你真的想要一个肯定停止或没有停止的程序，那么你就可以修复那些“不知道”单元，就像我们摆脱编译器警告一样。我想我们都会惊讶于经常尝试解决这个通常不可能解决的问题。

Answer 4

作为一名日常程序员，我认为继续沿着路径继续解决停止式问题是值得的，即使你只接近这个限制并且永远不会达到它。正如您所指出的，病毒扫描证明是有价值的。谷歌搜索不会假装是“为我找到最好的X”的绝对答案，但它也非常有用。如果我释放出一种新型病毒（muwahaha），是否会创建一个更大的解决方案集，或者只是在现有问题区域投射灯？无论技术差异如何，有些人都会务实地开发并收取后续“检测和删除”服务的费用。

我期待着您的其他问题的真实科学答案......

Answer 5

顺便说一下，我认为模板的图灵完整性表明停止被高估了。大多数语言保证他们的编译器会停止;不是这样的C ++。这会减少C ++作为一种语言吗？我不这么认为;它有许多缺陷，但并不总是停止的编译不是其中之一。

Answer 6

如果你在一般情况下看一下，停止问题真的很有意思，因为如果Halting问题是可判定的，所有其他不可判定的问题也可以通过减少来判定。

所以，我对这个问题的看法是，不，在重要的情况下这并不容易。也就是说，在现实世界中，这可能不是什么大问题。

另请参阅：http://en.wikipedia.org/wiki/Halting_problem#Importance_and_consequences

Answer 7

我不知道人们认为它有多难，所以我不能说它是否更容易。但是，您的观察结果是正确的，即问题的不可判定性（通常）并不意味着该问题的所有实例都是不可判定的。例如，我可以很容易地告诉你像while false do something这样的程序终止（假设while和false的明显语义）。

你提到的像终结者项目这样的项目显然存在（甚至可能在某些情况下有效），所以很明显并非一切都没有希望。还有一个竞赛（我相信每年）都试图证明重写系统终止的工具，它们基本上是一个计算模型。但在许多情况下，终止是非常难以证明的。

查看它的最简单方法可能是将不可判定性视为问题实例化复杂性的最大值。每个实例化都在一个小到达这个最大值的范围内，并且具有更高的最大值，通常你的实例化也更加平均。

Answer 8

问题不明确的事实并不意味着它没有意义：恰恰相反！所以，是的，我们没有一个有效和统一的程序来解决所有程序的终止（以及许多其他软件问题）这一事实并不意味着不值得寻找部分解决方案。从某种意义上说，这就是我们需要软件工程的原因：因为我们不能将任务委托给计算机。

然而，你的问题的标题有点误导。我同意DrPizza：终止问题与人们的想法一样困难。 此外，我们不必担心一般情况这一事实并不意味着终止问题被高估：值得寻找部分解决方案 beacuse 我们知道一般解决方案很难

最后，关于依赖类型和子递归语言的问题虽然部分相关，但实际上是不同的问题，我不确定是否要将它们混合在一起。