有调试生产功能程序的实际经验吗？
我感兴趣的是使用哪些工具和方法来诊断大型功能程序中的缺陷。 有哪些工具有用？ 我目前的理解是“printf”调试（例如添加日志记录和重新部署）是通常使用的。
如果您已经调试过一个功能系统，那么它与调试使用 OO 或过程语言构建的系统有何不同？
I'm interested in what tools and methods are used for diagnosing flaws in large scale functional programs. What tools are useful? My current understanding is that 'printf' debugging (e.g. add logging and redeploy) is what is typically used.
If you've done debugging of a functional system what was different about it then debugging a system built with an OO or procedural language?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
遗憾的是，
printf调试似乎是 Standard ML、Objective Caml 和 Haskell 的实践状态。 在交互式读取-评估-打印循环中需要进行一些调试，但是一旦您的应用程序达到 25,000 或 50,000 行，那么它的用处就不那么大了。如果您足够幸运使用 Haskell，有一个例外：QuickCheck对于测试和调试不可或缺。 QuickCheck 甚至可以用于 Haskell 和 C 代码的组合，正如 Xmonad 窗口管理器 的经验所证明的那样。
值得注意的是，1990 年左右，Andrew Tolmach 为新泽西州的 Standard ML 构建了一个非常好的时间旅行调试器，但人们认为它不值得维护。 还值得注意的是，OCaml 调试器（也是时间旅行调试器）一度仅适用于字节码，这很不方便，并且拒绝违反抽象障碍，这使得它毫无用处。 这是大约 3.07 版本左右； 也许情况有所改善。
同样是在 20 世纪 90 年代初，Henrik Nilsson 为 Haskell 构建了一个有趣的调试器，但它的主要作用是防止调试器意外更改程序的评估行为。 这很有趣，但仅限于懒惰评估的小孩子。
作为使用所有这三种语言构建或开发大型应用程序的人，我发现游戏的状态令人沮丧。
Sadly,
printfdebugging seems to be the state of practice for Standard ML, Objective Caml, and Haskell. There's a little bit of debugging at the interactive read-eval-print loop, but once your app hits 25,000 or 50,000 lines that's less useful.If you're lucky enough to be using Haskell, there's an exception: QuickCheck is indispensible for testing and deubgging. QuickCheck can be used even on combinations of Haskell and C code, as demonstrated by experience with the Xmonad window manager.
It's worth noting that around 1990 Andrew Tolmach built a very nice time-travel debugger for Standard ML of New Jersey, but that it was not considered worth maintaining. It's also worth noting that at one point the OCaml debugger (also a time-travel debugger) worked only on bytecode, which was inconvneient, and refused to violate abstraction barriers, which made it useless. This was around release 3.07 or so; perhaps things have improved.
Also in the early 1990s, Henrik Nilsson built an interesting debugger for Haskell, but mostly what it did was prevent the debugger from accidentally changing the evaluation behavior of the program. This was interesting, but only to lavzy-evaluation weenies.
As someone who has built or worked on large applications in all three of these languages, I find the state of play depressing.
我们在工作（Haskell 商店）中使用的主要工具是：
The main tools we use at work (a Haskell shop) are:
我当前的工作是实现新功能并支持用 ocaml 和 C# 实现的大型系统。 大多数“逻辑”是用 caml 实现的，GUI 和数据访问是用 C# 实现的。 调试技术与您描述的大量日志记录和断言非常相似，以找出问题所在。
此外，我们还有大量的单元测试，它们只是用于测试逻辑并帮助发现任何回归错误的 caml 脚本。
我们还使用持续集成来检查构建并运行夜间测试脚本，包括通过我们的“自动化”样式脚本接口对 GUI 进行一些自动化测试。
我经常使用 C# 调试器来调试应用程序的 C# 部分，ocaml 调试器在 Windows 下仍然可以工作，所以我们不使用它。 尽管我们希望有一天能够解决这个问题，但这并不是我们的首要任务。 我偶尔使用 Windbg 来调查托管和非托管内存问题，尽管事实证明这是由 C# 中实现的第三方组件引起的。
总的来说，没有什么异常，但似乎工作正常，我们没有看到太多的生产问题。
谢谢，
抢
My current job is to implement new features and support a large system implemented in ocaml and C#. Most of the "logic" is implemented in caml and the GUI and data access is in C#. The debugging techniques are pretty much as you describe lots of logging and assert to work out what's gone wrong.
Additionally we have a large number of unit tests, which are just caml scripts for testing the logic and help to spot any regression errors.
We also use continuous integration to check the build and run nightly test scripts, including some automated testing of the GUI though our "automation" style scripting interface.
I quite often use the C# debugger for debugging the C# portion of the application, the ocaml debugger does yet work under windows so we don't use it. Although we hope one day we may fix this but it isn't top of our priority list. I have occasionally used windbg to investigate managed and unmanaged memory problems, though this turned out to be caused by a third party component implemented in C#.
So overall, nothing out of the ordinary but it seems to work okay, we don't see too many production problems.
Thanks,
Rob
F# 具有 Visual Studio 集成，因此您可以将调试器附加到程序并设置断点、监视等，就像使用任何其他 .NET 语言一样。
但是，我更喜欢通过编写可以单独进行单元测试的简短函数来尽可能避免调试。
F# has Visual Studio integration, so you can attach the debugger to your program and set breakpoints, watches, etc, just like with any other .NET language.
However, I prefer to avoid debugging as much as possible, by writing short functions that I can unit-test individually.
几年前，当我这样做时，我必须结合使用 printf 调试和 QuickCheck。 这些天我也会使用 ghci 内置调试器。
最头疼的其实是懒惰造成的时空泄露。 对于这些问题似乎仍然没有一个好的答案：只需进行大量的分析并继续尝试找出答案即可。
A couple of years ago when I did this I had to use a combination of printf debugging and QuickCheck. These days I would also use the ghci built-in debugger.
The biggest headache was actually laziness causing space-time leaks. There still doesn't seem to be a good answer to these: just do lots of profiling and keep trying to figure it out.
OCaml 和 F# 都有出色的调试器。 OCaml 是时间可逆的。 F# 具有出色的 IDE 和多线程支持。
OCaml and F# both have excellent debuggers. OCaml's is time reversible. F#'s has excellent IDE and multithreading support.