Мне интересно, какие инструменты и методы используются для диагностики недостатков в крупномасштабных функциональных программах. Какие инструменты полезны? Мое настоящее понимание заключается в том, что отладка "printf" (например, добавление журнала и повторное развертывание) - это то, что обычно используется.
Если вы сделали отладку функциональной системы, что было по-другому, тогда отладка системы, построенной с помощью OO или процедурного языка?
К сожалению, отладка printf, по-видимому, является состоянием практики для стандартного ML, Objective Caml и Haskell. Там немного отладки в интерактивном режиме чтения-eval-print, но как только ваше приложение попадает на 25 000 или 50 000 строк, которые менее полезны.
Если вам посчастливилось использовать Haskell, , там исключение: QuickCheck является незаменимым для тестирования и дезинфекции. QuickCheck можно использовать даже в комбинациях кода Haskell и C, о чем свидетельствует опыт работы с диспетчером окон Xmonad.
Стоит отметить, что в 1990 году Андрей Толмах построил очень хороший отладчик времени для стандартного ML Нью-Джерси, но его не считали целесообразным. Стоит также отметить, что в какой-то момент отладчик OCaml (также отладчик во времени) работал только на байт-коде, который был неудобным и отказался нарушать барьеры абстракции, что сделало его бесполезным. Это было вокруг выпуска 3.07 или около того; возможно, вещи улучшились.
Также в начале 1990-х годов Хенрик Нильссон создал интересный отладчик для Haskell, но в основном это помогло отладчику случайно изменить оценочное поведение программы. Это было интересно, но только для lavzy-оценки weenies.
Как кто-то, кто создал или работал над большими приложениями во всех трех этих языках, , я обнаружил, что состояние игры удручает.
Основными инструментами, которые мы используем на работе (магазин Haskell), являются:
Моя текущая задача - реализовать новые функции и поддерживать большую систему, реализованную в ocaml и С#. Большая часть "логики" реализована в caml, а GUI и доступ к данным - в С#. Методы отладки в значительной степени связаны с тем, как вы описываете много протоколирования и утверждаете, чтобы понять, что пошло не так.
Кроме того, у нас есть большое количество модульных тестов, которые являются просто скриптами для проверки логики и помогают выявлять любые ошибки регрессии.
Мы также используем непрерывную интеграцию для проверки сценариев сборки и запуска ночных тестов, включая некоторые автоматизированные проверки графического интерфейса, но наш интерфейс сценариев стиля "автоматизации".
Я довольно часто использую отладчик С# для отладки части С# приложения, отладчик ocaml все еще работает под окнами, поэтому мы его не используем. Хотя мы надеемся, что однажды мы сможем это исправить, но это не верхний список приоритетов. Я иногда использовал windbg для исследования проблем с управляемой и неуправляемой памятью, хотя это оказалось вызвано сторонним компонентом, реализованным на С#.
В общем, ничего необычного, но, похоже, все в порядке, мы не видим слишком много производственных проблем.
Спасибо, Rob
F # имеет интеграцию с Visual Studio, поэтому вы можете присоединить отладчик к своей программе и установить точки останова, часы и т.д., как и с любым другим языком .NET.
Однако я предпочитаю избегать отладки как можно больше, написав короткие функции, которые я могу индивидуально тестировать.
Пару лет назад, когда я это сделал, мне пришлось использовать комбинацию отладки printf и QuickCheck. В эти дни я бы также использовал встроенный отладчик ghci.
Самая большая головная боль была на самом деле лени, вызывающая утечки пространства-времени. По-прежнему не кажется им хорошим ответом: просто делайте много профилирования и продолжайте пытаться понять это.
OCaml и F # имеют отличные отладчики. OCaml обратим время. F # имеет отличную поддержку IDE и многопоточности.