调试生产功能程序的任何实际经验?

时间:2008-12-26 04:59:29

标签: debugging haskell f# functional-programming scheme

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

如果您已经完成了对功能系统的调试,那么它是否有不同之处,然后调试使用OO或过程语言构建的系统?

6 个答案:

答案 0 :(得分:12)

可悲的是,printf调试似乎是Standard ML,Objective Caml和Haskell的实践状态。在交互式读取 - 评估 - 打印循环中进行了一些调试,但是一旦你的应用程序达到25,000或50,000行就不那么有用了。

如果你有幸使用Haskell,那么会有例外QuickCheck必不可少的,用于测试和重新发布。 QuickCheck甚至可以用于Haskell和C代码的组合,如Xmonad window manager的经验所示。

值得注意的是,1990年左右,Andrew Tolmach为新泽西州的Standard ML建立了一个非常好的时间旅行调试器,但它不值得维护。值得注意的是,OCaml调试器(也是一个时间旅行调试器)在某一点上只对字节码起作用,这是不方便的,并且拒绝违反抽象障碍,这使得它无用。这是3.07左右的发布;也许情况有所改善。

同样在20世纪90年代早期,Henrik Nilsson为Haskell构建了一个有趣的调试器,但其主要功能是阻止调试器意外地改变程序的评估行为。这很有趣,但仅限于评价维恩。

作为使用这三种语言构建或使用大型应用程序的人,我发现游戏状态令人沮丧

答案 1 :(得分:6)

我们在工作中使用的主要工具(Haskell商店)是:

  1. QuickCheck
  2. HPC:视觉Haskell程序覆盖工具(我们在内部开发)
  3. 记录/ printf的/跟踪
  4. 有时,the GHCi debugger

答案 2 :(得分:3)

我目前的工作是实现新功能并支持在ocaml和C#中实现的大型系统。大多数“逻辑”是在caml中实现的,GUI和数据访问是在C#中。调试技术就像你描述大量的日志记录和断言来解决出了什么问题一样。

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

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

我经常使用C#调试器来调试应用程序的C#部分,ocaml调试器在windows下工作,所以我们不使用它。虽然我们希望有一天我们可以解决这个问题,但它不是我们优先考虑的重点。我偶尔使用windbg来调查托管和非托管内存问题,但事实证明这是由在C#中实现的第三方组件引起的。

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

谢谢, 罗布

答案 3 :(得分:3)

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

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

答案 4 :(得分:1)

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

最令人头疼的事实是懒惰造成了时空泄漏。对于这些似乎仍然没有一个好的答案:只需进行大量的分析并继续尝试解决这个问题。

答案 5 :(得分:1)

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