16

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

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

4

6 回答 6

12

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

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

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

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

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

于 2008-12-26T07:22:03.780 回答
6

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

  1. 快速检查
  2. HPC：可视化 Haskell 程序覆盖工具（我们在内部开发）
  3. 记录/printf/trace
  4. 有时，GHCI 调试器
于 2009-04-10T17:16:24.977 回答
3

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

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

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

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

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

谢谢，罗伯

于 2008-12-26T05:27:56.520 回答
3

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

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

于 2009-01-14T04:45:24.487 回答
1

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

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

于 2008-12-26T16:05:06.890 回答
1

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

于 2009-04-10T13:03:03.463 回答