当我在这里谈论停止问题时，听起来不终止是要避免的事情，并且停止问题使得无法知道程序/算法是否良好。
但是当我想到它时，终止程序不是例外而不是规则吗？我可以想到一类预计会在有限时间内终止的应用程序：编译器。其他一切，从我正在使用的网络浏览器，到桌面环境，到文本编辑器，到外壳，再到托管 SO 的服务器，再到操作系统本身，都不应该自行终止。哎呀，即使是包管理器也应该要求用户确认。除非用户或系统管理员另有说明，否则它们都打算无限期地运行。
我的观点是，它真的很糟糕，以至于你无法证明某事会终止吗？如果有的话，证明某些东西会在有限的时间内退出将更像是一个错误而不是相反。
我看到了您的逻辑，但是虽然您提到的这些程序在无限循环中运行直到终止，您仍然可以随时使用退出功能终止它们。非确定性终止的问题是您不知道程序何时会释放对其正在执行的操作的控制，以便可以终止它。
考虑一下。您编写一个程序，它完成一个循环并再次开始它的循环。每个循环都类似于程序终止。但不是关闭程序，而是要求它重新开始。如果您在该程序中对无限循环进行函数调用，则程序将注意力集中在该函数上，从而有效地阻止所有其他功能，直到该循环完成为止。提示，从来没有。这被用户感知为程序冻结。
终止程序不是重点。这只是一个易于解释的计算终止的情况。这是一个实际的例子：
当您访问网页时，您可能会开始运行一些 Javascript。根据代码嵌入页面的方式，您可能必须等待此脚本终止，然后才能完全显示网页。如果脚本没有在特定时间限制内终止，您将收到如下消息：
（图示为 Chrome 对话框）
您应该以某种方式决定脚本是否正在取得进展，如果再多一点时间就会完成，或者它是否陷入无限循环。你可能不知道答案，所以你猜。你等到你厌倦了等待，然后放弃并杀死它，不知道当你按下按钮时它是否只剩下 1 秒。
Chrome 不会告诉您该脚本已无可救药地卡住并且永远不会终止，因为检测无可救药卡住的脚本需要解决停机问题。
它也不仅仅是页面加载。Javascript（在 Web 客户端上下文中）是事件驱动的。当外部事件发生时（即您单击表单提交按钮）调用函数，并且在函数返回（终止）之前不会处理该事件。非终止脚本是一个大问题。