Как выглядит ваш рабочий процесс на Лиспе? [закрыто]

В настоящее время я изучаю Lisp, исходя из языковой прогрессии, которая называется Locomotive BASIC -> Z80 Assembler -> Pascal -> C -> Perl -> C # -> Ruby. Мой подход заключается в том, чтобы одновременно:

• написать простой веб-скребок, используя SBCL, QuickLisp, closure-html и drakma
• смотреть лекции SICP

Я думаю, что это работает хорошо; Я разрабатываю хорошие «очки для Лисп», так что теперь я могу довольно легко читать Лисп. Я также получаю представление о том, как работает экосистема Lisp, например, Quicklisp для зависимостей.

Однако мне действительно не хватает ощущения того, как на самом деле работает опытный Лиспер .

Когда я пишу код для .NET, у меня установлена ​​Visual Studio с ReSharper и VisualSVN. Я пишу тесты, я реализую, я рефакторинг, я фиксирую. Затем, когда мне достаточно этого, чтобы закончить рассказ, я пишу несколько AUAT. Затем я запускаю сборку Release на TeamCity, чтобы предоставить клиенту новую функциональность для тестирования и, надеюсь, утверждения. Если это приложение требует инсталлятора, я использую WiX или InnoSetup, очевидно, собирая инсталлятор через систему CI.

Итак, мой вопрос: как опытный Лиспер, как выглядит ваш рабочий процесс? Ты работаешь в основном в REPL или в редакторе? Как вы проводите юнит-тесты? Непрерывная интеграция? Упаковка и развертывание? Когда вы садитесь за свой стол, выпаривая кружку кофе с одной стороны и фотографию Джона Маккарти в рамке с другой, что вы делаете ?

В настоящее время я чувствую, что справляюсь с кодированием на Лиспе, но не с разработкой на Лиспе ...

Большинство людей на comp.lang.lisp и Lisp Forum рекомендуют комбинацию Emacs и SLIME, предполагая, что вы не хотите платить за коммерческую реализацию, такую ​​как Allegro или LispWorks. Видео SLIME иллюстрирует рабочий процесс. Я использую Emacs и SLIME для разработки личных программ дома, и комбинация может быть очень эффективной.

SLIME дает вам интеграцию между Emacs и REPL. Обычно я загружаю все свои файлы, а затем открываю тот, над которым я работаю, в Emacs. После ввода или изменения каждой функции я нажимаю C-x C-e, что выполняет определение функции в REPL. Затем я могу переключиться в буфер REPL и попробовать функцию. Вся история REPL доступна и редактируется с использованием стандартных последовательностей клавиш Emacs, поэтому можно легко повторять вызовы функций с различными параметрами.

Я работаю в основном с Clojure, и вот мои настройки:

1. Eclipse IDE (я использую это, поскольку я также много работаю на Java, иногда в том же проекте, что и Clojure)
2. Плагин против часовой стрелки для Clojure (включая REPL)
3. Maven для управления зависимостями и сборками
4. Egit для контроля исходного кода

Рабочий процесс при кодировании обычно такой:

1. Откройте REPL, загружая все текущие исходные файлы
2. Код и тест в REPL
3. Когда я доволен некоторым кодом, скопируйте / вставьте обратно в исходный файл
4. Иногда перезагружайте REPL (или когда я безвозвратно испортил пространство имен, или просто чтобы убедиться, что все еще работает в исходных файлах)
5. Также пишите тесты в исходные файлы, которые запускаются автоматически при каждой сборке Maven. Иногда неофициальные тесты, которые я только что провел на REPL, превращаются прямо в модульные тесты.
6. Фиксация и т. Д. На этом этапе - обычный рабочий процесс разработки

В целом, он не слишком отличается от обычного рабочего процесса Java / C #, за исключением более интерактивного использования REPL во время разработки.

В дополнение к другим ответам, я делаю комбинацию типа «Подумай о проблеме, затем запиши решение» и «Начни с ответа, и итеративно приведи свою программу в форму». Обычно в середине. То, что я делаю, я начинаю с общего представления о том, как должна выглядеть моя программа, а затем я начинаю писать ее, пытаясь получить новые знания о проблемной области по ходу работы, чтобы пересмотреть свой подход. На практике это означает, что я много экспериментирую и пишу много брошенного кода. Я пробую разные подходы и могу очень быстро менять направление. Лисп хорош для такого развития. Вот почему я так не люблю TDD, я должен знать, что я хочу сделать в первую очередь, чтобы эффективно использовать TDD.

Еще одна важная вещь, которую я пытаюсь сделать, это больше думать о протоколе между различными частями программы. В отличие от других ОО-языков, в Common Lisp CLOS больше ориентирован на концепцию универсальной функции, методы IOW живут вне классов и находятся в центре внимания разработки. Иногда я просто начинаю с набора GF, определяющих нужный мне протокол, я пишу простую реализацию и использую ее для уточнения протокола, прежде чем написать реальную реализацию. Скажем, я пишу слой, который хранит кучу постов в блоге, у меня может быть набор GF, которые определяют, как посты блога создаются, редактируются и ищутся, и я бы написал простую реализацию, которая сохраняет посты блога в списке в памяти. и после того, как я доволен своим протоколом, я пишу реализацию, которая сохраняет записи блога в базе данных или записывает их в файлы.

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

Также важный момент: используйте вашу среду в полной мере, узнайте, как использовать различные параметры компиляции, чтобы компилировать код с большей информацией отладки, воспользуйтесь тем фактом, что lisp может быть скомпилирован и интерпретирован. Используйте интроспективные средства lisps, такие как MOP, используйте функции slimes для поиска документации, используйте инспектор для поиска внутри объектов, регулярно просматривайте гиперспек, относитесь к вашей системе больше как к ОС, чем к статическому компилятору для вашего кода, это намного больше мощный, чем это.

Для новичка, lisp не так уж важен для победы над python и ruby, но, по мере того, как вы становитесь более опытным в этом, вы получаете огромные победы над меньшими средами.

Самое главное, вы должны повеселиться и полюбить этот язык, иногда его просто обескуражить и использовать популярные на данный момент языки blub. Если вы будете придерживаться LISP, он вам отплатит.

Я склонен работать в редакторе, который имеет связь с REPL (обычно редактирование в emacs и использование SLIME в качестве моста к среде Common Lisp). Я стремлюсь начать как «снизу», так и «сверху», работая в середине, пересматривая дизайн по мере продвижения.

Что касается тестирования, вот почему у меня есть REPL. Я считаю, что это помогает тестировать код на ходу. Иногда я буду писать более формальные тесты или тесты (обычно, когда я нахожусь в стадии оптимизации). Имейте медленную, хорошо известную реализацию функциональности, экспериментируйте (в окне редактора) с кодом для оптимизированной версии, отправьте его в лежащий ниже код lisp и убедитесь, что он и быстрее, и возвращает те же результаты, что и медленный код.

Что касается упаковки, у меня есть некоторый служебный код, который поможет мне упаковать ASDF-устанавливаемые проекты, поместить их в репозиторий загрузки и управлять версиями.