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

Ответ 1

К сожалению, отладка 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.

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

Ответ 2

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

• QuickCheck
• HPC: визуальный инструмент для охвата программ Haskell (мы разработали это в доме)
• Logging/Printf/след
• Иногда отладчик GHCi

Ответ 3

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

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

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

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

В общем, ничего необычного, но, похоже, все в порядке, мы не видим слишком много производственных проблем.

Спасибо, Rob

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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