Какой-нибудь реальный опыт отладки производственной функциональной программы?

Question

Меня интересует, какие инструменты и методы используются для диагностики недостатков в крупномасштабных функциональных программах. Какие инструменты полезны? В настоящее время я понимаю, что обычно используется отладка printf (например, добавление журнала и повторное развертывание).

Если вы выполнили отладку функциональной системы, что в этом отличалось, тогда отладка системы, построенной на ОО или процедурном языке?

Answer 1

К сожалению, printf отладка, кажется, является практикой для Стандартного ML, Objective Caml и Haskell. В интерактивном цикле read-eval-print есть небольшая отладка, но как только ваше приложение набирает 25 000 или 50 000 строк, это становится менее полезным.

Если вам повезло использовать Haskell, есть исключение : QuickCheck необходимо для тестирования и отладки. QuickCheck можно использовать даже для комбинаций кода на Haskell и C, как показывает опыт работы с оконным менеджером Xmonad .

Стоит отметить, что около 1990 года Эндрю Толмач создал очень хороший отладчик путешествий во времени для Standard ML из Нью-Джерси, но его не стоило поддерживать. Также стоит отметить, что в какой-то момент отладчик OCaml (также отладчик путешествий во времени) работал только с байт-кодом, что было неудобно, и отказывался нарушать барьеры абстракции, что делало его бесполезным. Это было примерно в версии 3.07 или около того; возможно, все улучшилось.

Также в начале 1990-х годов Хенрик Нильссон создал интересный отладчик для Haskell, но главным образом он предотвратил случайное изменение отладчиком поведения программы при оценке. Это было интересно, но только для лавиш-оценщиков.

Как человек, который создавал или работал над большими приложениями на всех трех этих языках, я нахожу состояние игры удручающим .

Answer 2

Основные инструменты, которые мы используем на работе (магазин Haskell):

1. QuickCheck
2. HPC : средство визуального охвата программы на Haskell (мы разработали его самостоятельно)
3. Вход / Printf / след
4. Иногда отладчик GHCi

Answer 3

F # имеет интеграцию с Visual Studio, поэтому вы можете присоединить отладчик к вашей программе и установить точки останова, часы и т. Д., Как и с любым другим языком .NET.

Однако я предпочитаю по возможности избегать отладки, написав короткие функции, которые я могу тестировать по отдельности.

Answer 4

Моя текущая работа - внедрять новые функции и поддерживать большую систему, реализованную в ocaml и C #. Большая часть «логики» реализована в caml, а графический интерфейс и доступ к данным - в C #. Методы отладки в значительной степени похожи на то, как вы описываете множество журналов и утверждаете, что выяснили, что пошло не так.

Кроме того, у нас есть большое количество модульных тестов, которые являются просто caml-скриптами для проверки логики и помогают обнаружить любые ошибки регрессии.

Мы также используем непрерывную интеграцию для проверки сборки и запуска сценариев ночного тестирования, в том числе некоторых автоматических тестирований GUI через наш интерфейс сценариев в стиле «автоматизации».

Я довольно часто использую отладчик C # для отладки части приложения на C #, отладчик ocaml все еще работает под окнами, поэтому мы его не используем. Хотя мы надеемся, что однажды мы сможем это исправить, но это не самое главное в нашем списке приоритетов. Иногда я использовал windbg для исследования проблем с управляемой и неуправляемой памятью, хотя это, как оказалось, вызвано сторонним компонентом, реализованным в C #.

Итак, в целом, ничего необычного, но, похоже, все работает хорошо, мы не видим слишком много производственных проблем.

Спасибо, Rob

Answer 5

OCaml и F # оба имеют отличные отладчики. OCaml's время обратимо. F # имеет отличную IDE и поддержку многопоточности.

Answer 6

Пару лет назад, когда я сделал это, мне пришлось использовать комбинацию отладки printf и QuickCheck. В эти дни я также использовал встроенный отладчик ghci.

Самая большая головная боль была на самом деле лень, вызывающая утечки пространства-времени. Похоже, на этот вопрос пока что нет хорошего ответа: просто сделайте много профилирования и продолжайте пытаться выяснить это.