有调试生产功能程序的实际经验吗？答案

【问题标题】：Any real world experience debugging a production functional program?有调试生产功能程序的实际经验吗？
【发布时间】：2010-09-28 10:53:37
【问题描述】：

我对用于诊断大型功能程序中的缺陷的工具和方法感兴趣。什么工具有用？我目前的理解是“printf”调试（例如添加日志记录和重新部署）是通常使用的。

如果您已经调试过功能系统，那么调试使用 OO 或过程语言构建的系统有什么不同？

【问题讨论】：

标签： debugging haskell f# functional-programming scheme

【解决方案1】：

我们在工作中使用的主要工具（Haskell 商店）是：

QuickCheck
HPC: 可视化 Haskell 程序覆盖工具（我们内部开发）
记录/printf/trace
有时，the GHCi debugger

【讨论】：

【解决方案2】：

OCaml 和 F# 都有出色的调试器。 OCaml 是时间可逆的。 F# 具有出色的 IDE 和多线程支持。

【讨论】：

【解决方案3】：

F# 集成了 Visual Studio，因此您可以将调试器附加到您的程序并设置断点、监视等，就像使用任何其他 .NET 语言一样。

但是，我更愿意通过编写可以单独进行单元测试的简短函数来尽可能避免调试。

【讨论】：

【解决方案4】：

几年前，当我这样做时，我不得不结合使用 printf 调试和 QuickCheck。这些天我也会使用 ghci 内置调试器。

最令人头疼的实际上是懒惰导致时空泄漏。这些似乎仍然没有一个好的答案：只需进行大量分析并继续尝试找出答案。

【讨论】：

【解决方案5】：

遗憾的是，printf 调试似乎是标准 ML、Objective Caml 和 Haskell 的实践状态。在交互式读取-评估-打印循环中进行了一些调试，但是一旦您的应用程序达到 25,000 或 50,000 行，就不太有用了。

如果您有幸使用 Haskell，有一个例外：QuickCheck 对于测试和调试必不可少。 QuickCheck 甚至可以用于 Haskell 和 C 代码的组合，正如 Xmonad window manager 的经验所证明的那样。

值得注意的是，大约在 1990 年，Andrew Tolmach 为新泽西的标准 ML 构建了一个非常好的时间旅行调试器，但它被认为不值得维护。还值得注意的是，OCaml 调试器（也是一种时间旅行调试器）有时只在字节码上工作，这很不方便，并且拒绝违反抽象障碍，这使得它毫无用处。这大约是 3.07 版左右；也许情况有所改善。

同样在 1990 年代初期，Henrik Nilsson 为 Haskell 构建了一个有趣的调试器，但它所做的主要是防止调试器意外更改程序的评估行为。这很有趣，但只适用于 lavzy-evaluation 的小伙伴们。

作为一个使用所有这三种语言构建或开发过大型应用程序的人，我觉得游戏状态令人沮丧。

【讨论】：

有趣...顺便说一句，您的应用程序中有哪些错误？对于我编写的简单程序，我发现在 Haskell 中编码时很难引入 bug :)
哦，最后一次真正令人兴奋的是，当我使用 e1 的实时变量破坏了 GHC 的代码生成器时，我应该使用 e2。一个字错了，花了一整天才找到。 GHC 是，嗯，有点缺乏单元测试 :-)

【解决方案6】：

我目前的工作是实现新功能并支持用 ocaml 和 C# 实现的大型系统。大多数“逻辑”在 caml 中实现，GUI 和数据访问在 C# 中。调试技术与您描述的大量日志记录和断言非常相似，以找出问题所在。

此外，我们还有大量的单元测试，它们只是用于测试逻辑并帮助发现任何回归错误的 caml 脚本。

我们还使用持续集成来检查构建并运行夜间测试脚本，包括通过我们的“自动化”样式脚本界面对 GUI 进行一些自动化测试。

我经常使用 C# 调试器来调试应用程序的 C# 部分，ocaml 调试器在 windows 下还可以工作，所以我们不使用它。虽然我们希望有一天我们可以解决这个问题，但这并不是我们的首要任务。我偶尔使用 windbg 来调查托管和非托管内存问题，但结果证明这是由用 C# 实现的第三方组件引起的。

总的来说，没有什么特别的，但它似乎工作正常，我们没有看到太多的生产问题。

谢谢，抢

【讨论】：