Грамотный Хаскель (.lhs) и Пикша

На данный момент я использую только Haddock, но после просмотра некоторых действительно интересных примеров (например, этой сути) грамотного Хаскелла, мне интересно попробовать это в проекте.

Вопросы, которые я получил, следующие:

  • Что ты пишешь как комментарии Хэддока и что ты пишешь в грамотной части?

  • Как вы масштабируете грамотное программирование для нескольких файлов? Может кто-нибудь указать мне пример, где грамотное программирование используется в пакете с несколькими модулями? Каков ваш опыт использования грамотного программирования в больших пакетах?

  • Какой вкус (уценка, латекс, ...) грамотного Хаскелла предпочтительнее?

  • Почему вы программируете на грамотном Хаскеле или простом ванильном Хаскеле? Вы программируете в обоих стилях и если да, то почему?

  • Вы предпочитаете блочный стиль (\begin{code}) или в стиле птицы (>)? Зачем?

2 ответа

Решение

Я писал много грамотных программ.

Что ты пишешь как комментарии Хэддока и что ты пишешь в грамотной части?

Документация по внешнему API входит в комментарии Haddock. Все остальное переходит в грамотную часть. "Все остальное" может включать в себя:

  • Внутренние инварианты структур данных
  • Почему ты так делаешь
  • Что такое дизайн кода
  • Почему этот дизайн был выбран, какие другие проекты были опробованы

Как вы масштабируете грамотное программирование для нескольких файлов?

Точно так же, как вы масштабируете большой документ LaTeX на несколько файлов: один файл на модуль, затем гигантский файл, который \includeС их всех.

Может кто-нибудь указать мне пример, где грамотное программирование используется в пакете с несколькими модулями?

Это не Haskell, а компилятор Quick C-- - большая функциональная программа, написанная с использованием грамотного программирования.

Каков ваш опыт использования грамотного программирования в больших пакетах?

Грамотное программирование очень хорошо подходит для документирования сложных, сложных или сложных модулей. Для большинства простых модулей достаточно документации внешнего API (например, Haddock). И ни одна грамотная программа на самом деле не даст вам общую картину дизайна, который содержит более десятка модулей. Для этого вам нужны другие инструменты и методы.

Какой вкус (уценка, латекс,...) грамотного Хаскелла предпочтительнее?

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

Почему вы программируете на грамотном Хаскеле или простом ванильном Хаскеле? Вы программируете в обоих стилях и если да, то почему?

Мои коды на Haskell почти всегда полностью просты по двум причинам:

  • Я работаю со старшими людьми, которые имеют больше опыта в Haskell, и они отказались от грамотного Haskell. Только самые старые модули в их системе имеют шанс быть.lhs.

  • Для Haskell грамотное программирование является излишним. Одним из больших преимуществ инструмента грамотного программирования является то, что вы освобождаетесь от любых ограничений, которые определение компилятора или языка может накладывать на порядок появления вашего кода. Но у Haskell таких ограничений почти нет: перед использованием нет определения, и для определения типичной функции у меня есть выбор: letобязательный или where-связывающие вспомогательные имена (или оба). Грамотное программирование никогда не было просто модными комментариями, а с "грамотным" Haskell это почти все, что вы получаете. Это не стоит беспокоиться.

Вы предпочитаете блочный стиль (\begin{code}) или птичий стиль (>)? Зачем?

Я настоятельно предпочитаю блочный стиль:

  • Это примерно совместимо с любым другим инструментом грамотного программирования на планете. (Следы птиц уникальны для Хаскелла.)

  • Мой редактор лучше справляется со стилем блоков.

Если вы намереваетесь делиться программами в Интернете, я считаю, что комбинация грамотного haskell в стиле уценки с mathjax будет отличной комбинацией. Программа "Pandoc" очень хороша для того, чтобы использовать эту "markdown + lhs" в любом формате, который вы пожелаете, включая PDF или HTML. Если вы скажете Pandoc выводить в HTML, вы можете использовать -mathjax (или другие подобные флаги, если хотите), чтобы ваши латексные математические формулы отображались.

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

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

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

Таким образом, я добился хорошего успеха и рекомендую использовать стиль markdown + lhs, знаки доллара для встраивания латексных математических формул, стиля птицы и pandoc. Я бы порекомендовал писать программы, как если бы они были исследовательскими работами, и относился бы к самому хаскелю, как к математическим выражениям в исследовательской работе.

Другие вопросы по тегам