Кодеры за работой

Я даже нечасто пользуюсь всеми хитростями Emacs, хотя некоторые любят этим заниматься. Также масса народу пользуется интегрированными средами разработки — Visual Studio, Eclipse. Мне кажется, неприятие языков функционального программирования отчасти связано с тем, что мы не выпустили свою интегрированную среду разработки. Опять проблема курицы и яйца. Сейчас напирают на курицу — идет всплеск интереса к функциональному программированию. Надеюсь, что и за яйцо тоже возьмутся. Интегрированная среда для Haskell потребует серьезной разработки. Даже при таких оболочках, как Visual Studio или Eclipse, предстоит большая работа над красивым плагином, который бы делал все как надо.

Сейбел: В GHC есть цикл REPL, GHCI. Вы предпочитаете работать с Haskell интерактивно?

Пейтон-Джонс: Ну, сам я сейчас в основном редактирую и компилирую. Но другие просто живут в GHCI.

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

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

Тестирование необычайно важно для создания свойств. Очень полезна QuickCheck — библиотека Haskell, генерирующая случайные тесты для функции в зависимости от ее типа. И я старался понять, почему использую QuickCheck — очень приятный инструмент — меньше, чем мог бы. Видимо, потому, что меня беспокоят ситуации, когда трудно сгенерировать тестовые данные. Так или иначе, куча народу создает программы, от которых GHC просто воротит. Для этого у GHC и есть свой багтрекер.

Я обычно начинаю с чего-нибудь, что работает не так. Возможно, компилятор зависнет в каком-то месте, или откажется выполнять программу, которую должен выполнять, или станет генерировать неоптимальный код. Если он просто генерирует плохой код, я гляжу на него на разных стадиях компиляции и соображаю: «Здесь все в порядке, здесь тоже, а здесь нет — в чем дело?»

Сейбел: Как именно вы это делаете?

Пейтон-Джонс: В GHC есть флажки, которые позволяют выводить что-либо на печать.

Сейбел: Встроенные операторы печати для отладки?

Пейтон-Джонс: Да. Плюс к тому структура такая же, как у большинства компиляторов: на верхнем уровне есть конвейерная структура преобразований. Если что-то не так внутри какого-то из шагов, задача усложняется. Но я предпочитаю несложные методы отладки. Покажите мне программу до и после данного шага. Ага, я вижу, в чем ошибка! Если же не вижу, то могу использовать какой-нибудь из небезопасных операторов printf, чтобы понять, что происходит.

Есть разные отладчики для Haskell. Один из них, и просто отличный, написал в этом году студент летней школы, Пепе Иборра: это интерактивный отладчик, который теперь поставляется вместе с GHC. Я, правда, его мало использовал — он появился недавно, и, кроме того, не очень понятно, как пошагово проходить функциональную программу.

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

Я все это говорю, чтобы показать, что использую крайне примитивные техники отладки, например через небезопасные операторы printf. Тут нечем гордиться. Но долгое время ничего больше не было — по крайней мере, если брать GHC. Я выработал способы, которые делают для меня этот путь самым коротким.

Сейбел: Это как всегда. Зачем создавать новые отладчики, если люди довольствуются операторами печати?

Пейтон-Джонс: Это скорее культурное явление. Если перейти на отладчики платформы .NET, на которые потрачены десятки и сотни тысяч человекочасов, думаю, результат будет качественно иным. Вероятно, для хорошей работы отладчики требуют еще больше циклов разработки. Но зато в итоге получается образцово полезная вещь.

Возможно, вы разговаривали в основном с людьми академического склада и с теми, кто в силу возраста не привык к сложным отладчикам. Я бы не стал делать никаких общих выводов. И, конечно, не хочу принизить значение качественных отладчиков — особенно для сложных систем с множеством программных слоев. GHC очень прост сравнительно со средой .NET, где есть слои DOM и UML, и не знаю, что еще. Теперь вокруг столько примочек, что программная поддержка становится действительно важной.

Сейбел: Еще один способ создавать правильные программы — формальные доказательства. Что вы думаете об их полезности?