Блеск и нищета SLIME

Блеск
Реальная разработка на на любом из диалектов Lisp, а на Common Lisp так тем более, не мыслима без хорошо инструмента, предоставляющего удобный интерфейс к мощным возможностям среды. Нет, конечно можно пытаться писать на CL в блокноте nano и вызывать, скажем, SBCL из командной строки, но серьёзных вещей так не напишешь и очень скоро придёшь к мысли, что лучше использовать что-нибудь вроде Python. И сейчас SLIME является тем самым инструментом, который делает разработку на Common Lisp очень удобной. Без сомнения, на сегодняшний день SLIME является достижение Common Lisp-сообщества, без которого бы уровень популярности CL был бы значительно ниже. Собственно, на этом блеск заканчивается :(

Нищета
Начну с утверждения того, что SLIME не является современным программным обеспечением и не устремлён в будущее, а скорей основан на пережитках прошлого (когда ситуация с CL была куда хуже, чем сейчас). Это, фактически, цельный кусок кода, который не опирается ни на что, кроме конкретных реализаций, и не предоставляет миру ничего, кроме собственно самой IDE. Кому-то может показаться, что это и неплохо, но мне представляется, что совершенно не раскрыты потенциальные возможности, которые возникают при разработке инструмента подобного рода.

SLIME состоит из двух частей: ELisp-кода, обеспечивающее непосредственный функционал IDE на стороне Emacs и Lisp-side части (известной как SWANK), которая является сервером, работающим в рамках запущенного lisp-процесса, который предоставляет доступ к "внутренностям" lisp и взаимодействует с elisp-частью по сокетному соединению: такая архитектура обусловлена тем, что использование стандартных потоков ввода/вывода для взаимодействия между lisp-процессом и Emacs не может обеспечить необходимый уровень сервиса. Связующим звеном между двумя этими частями, естественным образом, является протокол взаимодействия. Наличие данного протокола дало возможность для разработки SWANK-сервера также и на Scheme, а теперь и на Clojure (см. swank-clojure). Подобная схема выглядит просто замечательно: с одной стороны возможны различные реализации swank для разных диалектов lisp, с другой стороны возможны различные клиентские части, не только для Emacs, но и например для Eclipse (см. cusp), да и заметно упрощается (особенно после появления cl-gtk2) разработка полноценной среды разработки на самом Common Lisp (думаю, для fun на это нашлось бы достаточно желающих). В общих чертах, картина выглядит замечательно, но... как известно кругом овраги, а по ним ходить...

Протокол
Самое больное место. Протокол не стабилен и может меняться от коммита к коммиту (релизов или версий фактически нет). Реализации для Common Lisp и Scheme входят в состав SLIME, и можно изменить их, изменить ELisp-часть, закоминить, и свежая версия из CVS (которую рекомендуют использовать разработчики) будет продолжать успешно работать. Но вот тот же swank-clojure внезапно отвалится. Это основная причина, почему для работы с swank-clojure рекомендуется использовать замороженную версию SLIME. И я думаю, что это одна из основных причин, почему cusp не получил активного развития. Сообщество Clojure, вообще может иметь очень большое значение. Насколько я понимаю, сейчас плагин для Eclips может быть написан непосредственно на самом Clojure, что резко повышают вероятность его появления (fun от разработки на Clojure будет несомненно больше, чем от традиционного написания кода на Java). В данный момент, есть возможность получить такой плагин, который будет подходить и для работы с Clojure, и для работы с Common Lisp, и для работы с Scheme. А это было бы очень и очень важно получить полноценную среду разработки на Common Lisp на базе Eclipse (как известно, далеко не все любят Emacs). Но вот как долго swank-clojure будет опираться на старую версию SLIME для меня вопрос так даже не стоит: наиболее вероятный вариант, что эти ребята просто форкнут его под свои нужды и пойдут своим путем. Т.е. путем стандартизации протокола SWANK, введения для него версий, можно надеяться объединить представителей различных диалектов lisp для работы над общим окружением. А текущая ситуация приведёт к увеличению разобщённости.

Модульность
Как наиболее активный пользователь RESTAS я понимаю, что было бы неплохо внедрить в SLIME несколько сервисов, для облегчения работ с ним. Например, я бы хотел иметь удобную, на уровне IDE, возможность просмотра активных virtual host, а для них карты маршрутов (с переходом к месту определения конкретного маршрута и т.п.). Хотел иметь специальную версию профайлера, ориентированную именно на разработку веб-приложений, и информированную о структуре сайта, ну и удобный доступ к нему через Emacs, а не REPL. Или что бы режим для работы с шаблонами cl-closure-template знал об способе их включения в сайт и мог бы упрощать их пере-компиляцию. В принципе, сейчас можно написать необходимый код, но он будет зависеть от возможностей SLIME, которые для этого как бы не предназначены и могу измениться уже в следующем коммите SLIME. Я думаю, что стандартизованный способ расширения возможностей SLIME для работы с конкретными системами был бы очень полезен во многих случаях, но его нет, SLIME это вещь в себе.

Common Lisp SWANK
Common Lisp реализация SWANK с одной стороны содержит в себе много уникального функционала для независимого от реализации доступа к внутренностям Common Lisp, а с другой стороны, значительная часть кода может быть сокращена за счёт использования таких библиотек, как bordeax-threads, usocket, closer-mop и т.п. Т.е. с одной стороны выполняется двойная работа, также выполненная в других библиотеках. А с другой стороны, имеющийся уникальный функционал фактически недоступен для использования в других системах. Отсутствие зависимостей, конечно, несколько упрощает распространение, но при этом и затрудняет развитие. На мой взгляд, упрощения распространения должно обеспечиваться другими средствами (например, штатными менеджерами дистрибутивов или системами подобными clbuild) и на первый план должна выходить простота разработки, которая бы позволила привлечь к работе большее количество разработчиков. Т.е. с одной стороны, Common Lisp SWANK мог бы опираться на существующие (но которых не было в момент зарождения SLIME) библиотеки (для работы с сокетами, потоками и т.п.), а функционал, для которого сейчас нет переносимых реализаций необходимо выносить в отдельные проекты (например, работу с профайлером или интроспекцию), которые могут быть полезными и иметь значение сами по себе, а Common Lisp SWANK выполнял бы роль локомотива в процессе развития этих решений.

Вывод: разбиение SLIME на отдельные части, стандартизация протокола и перепроектирование системы на основе современных представлений о "хорошем" дизайне программного обеспечения могло бы сыграть значительную роль в развитии и дальнейшей популяризации как Common Lisp, так и других диалектов lisp, а текущее положение дел наоборот, способствует стагнации.