Python против Common Lisp, рабочий процесс и экосистема (2019)

pythonпротивcommonlispрабочийпроцессиэкосистема2019

Я изучал Java и C в школе, я выучил Python сам, и это было облегчением. После 8 лет работы и выполнения побочных проектов на Python и JavaScript (в основном веб-разработчики, Django / Flask / AngularJS / Vuejs), я больше не удовлетворен общим опытом, поэтому я выбираю Common Lisp на своем языке.

Я здесь не для того, чтобы сравнивать сами языки, а для того, чтобы сравнивать их рабочий процесс и их экосистему. Это статья, которую я хотел бы прочитать раньше, когда я интересовался Лиспом, но был немного озадачен, потому что способ Лиспа всегда казался другим, и я не мог найти много голосов, чтобы объяснить это. Путь Python может быть не самым практичным или эффективным, Common Lisp не может быть мертвым языком. Я нахожу много «исправлений рабочего процесса», общих улучшений и хакерских возможностей на стороне CL, даже если иногда инструменты Python лучше.

Давайте погрузимся.

и спасибо корректорам.

Содержание

Интерактивность

В Python

, мы обычно перезапускаем все при каждом изменении кода, мы используйте точки останова: это занимает некоторое время, я нахожу это слишком повторяющимся и утомительным, требует повторного манипулирования данными, чтобы снова достичь состояния, в котором мы были для анализа и отладки нашей программы. Мы могли бы найти нестандартный, более интерактивный способ, но все же: веб-сервер должен перезапускаться, экземпляры объектов не обновляются после определения класса. Мы можем получить сообщение об ошибке ( - m pdb ), некоторые инструменты включают его (Werkzeug): знак того, что это хорошо. К сожалению, он не встроен, как в CL.

В Common Lisp , в REPL все намного интерактивнее. Даже разработка веб-приложений. При ошибке получаем интерактивный отладчик с трассировкой стека в нашем редакторе, нажимаем v и вуаля, мы находимся на проблемной линии. Конечно, мы можем отлавливать ошибки, чтобы избежать работы отладчика, или отключить его с помощью глобальных настроек. Мы можем возобновить выполнение программы из любого стекового фрейма. Нет необходимости перезапускать процесс. Переменные, которые мы определяем в REPL, остаются здесь. Если мы изменяем определение класса (скажем, удаляем поле), существующие экземпляры обновляются (лениво).

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

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

Вот видео , где разработчик определяет фиктивный интерфейс, делает его неудачным, разрабатывает его и тестирует быстро, взаимодействуя с REPL.

Код редактирования

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

Common Lisp : редактируем код по семантическим единицам. Мне нравится 79, что поначалу, конечно, странно, но так удобно. Мы можем перемещаться по выражениям вперед и назад, мы можем удалить все выражение «если» нажатием клавиши, отступы выполняются автоматически и т. Д. Есть другие плагины emacs . Паринфер приветствуется и в других редакторах.

На самом деле мы редактируем код с помощью скобок, которые не имеют такого большого значения, как абстрактное синтаксическое дерево. Для настоящего AST нам понадобится обходчик кода (например, Конкретное синтаксическое дерево ). Но поскольку синтаксис Лиспа основан на скобках, на практике опыт аналогичен.

У меня была попытка написать небольшой плагин, который поможет редактировать код Python, манипулируя AST ( red4e ). Сначала нам понадобится парсер AST. Была пара для Python 2, еще одна для Python 3 без аннотаций типов, в конечном итоге одна появилась пару лет спустя: это признаки нестабильности языка и экосистемы, и от разработчика требуется больше работы. Я пошел простым путем, вызвав каждую функцию в новый процесс Python, который, конечно, слишком медленный. traad является лучшим проектом, он может делать гораздо больше, но все же трудно ответить на такие вопросы, как перекрестные ссылки: «кто вызывает эту функцию» или «кто выполняет этот вызов функции», что встроены в SLIME. похож на протокол языкового сервера для Common Lisp в Emacs, его бэкэнд Swank не зависит от редактора.

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

Traad построен на подходе клиент-http-сервер, это идея, лежащая в основе LSP… это напоминает мне архитектуру SLIME! У него есть бэкэнд Swank и клиент (SLIME для Emacs, SLIMA для Atom,…). Таким образом, с момента своего создания он имеет современную архитектуру 🙂 Более того, он основан на стабильном языке, синтаксис которого не может гнить, и за его плечами десятилетия развития, поэтому мы можем быть уверены в этом инструменте. Сказано это потому, что вначале трудно понять, что такое SLIME.

Сама SLIME привязана к Emacs, и поэтому новичок может счесть пользовательский интерфейс непрактичным. Swank, однако, можно использовать вне Emacs, например, для Atom SLIMA , который теперь имеет все самые важные функции SLIME: REPL, встроенный отладчик, переход к определению, автозаполнение , интерактивный осмотр объектов и др.

Запуск, тестирование программы

Python : рабочий процесс по умолчанию – запускать команды в терминале. Прокрутите, прочтите вывод, скопируйте и вставьте вручную (или используйте не-UX-оптимальный termux или терминал внутри emacs), вернитесь в свой редактор. Введите команды без завершения, введите весь путь к одному модульному тесту ( pytest path / to / test.py::foo или настройте свой редактор и найдите хороший плагин, который совместим с вашим тестовым раннером (я не могу использовать отличный режим носа :().

Common Lisp : рабочий процесс по умолчанию заключается в том, чтобы делать все в интерактивном режиме в REPL, но некоторые люди по-прежнему используют подход «запись-компиляция-запуск». Следовательно, для всего есть встроенное завершение. Нам не нужно использовать оболочку (кроме случаев, когда время от времени запускают глобальные тесты или сборку системы), и это хорошо. Существует интерактивный отладчик. Мы можем в интерактивном режиме исправлять и повторно запускать код и тесты.

Вот

быстрая демонстрация того, как интерактивно исправить неудачные тесты: