[Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор версии
От: volk  
Дата: 09.03.09 13:53
Оценка: 77 (9) -2 :))) :)
Некоторое время назад я осуществил глубокое погружение в функциональное программирование. Не могу сказать, что овладел каким-то секретным знанием на этом пути, однако приобретенный опыт считаю ценным.

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

Я стартовал с изучения традиционного Лиспа и теперь попытаюсь описать некоторые плюсы и минусы этого подхода. Разнообразные фичи ФЯ здесь обсуждаться не будут. А будет обсуждаться сама возможность быстрого старта в Лиспе, наличие/отсутствие информации для начинающих, крутость кривой обучения, некоторые мифы про Лисп и отдельные подводные камни.


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





Часть 1. Как его готовить.

Это один из ключевых моментов всей истории. Выбор реализации языка и среды разработки определяет процентов на 80%, сможете ли вы пробиться через вторичные трудности и приступить собственно к программированию. Выбирать надо не столько диалект и реализацию Лиспа, сколько сопутствующую версию редактора.

Дело в том, что от редактора Лиспа требуется больше, чем просто синтаксическая подсветка текста. Редактор должен реализовывать Read-Eval-Print Loop (коротко REPL), или попросту говоря, возможность интерактивного исполнения пользовательского ввода.

Конечно, можно работать и в привычном для императивного программиста режиме "пишем -- запускаем -- смотрим, почему взорвалось". Тогда в качестве редактора сойдет даже блокнот или, например, ConTEXT. Однако использование REPL резко сокращает усилия на старте. Действительно, это чертовски удобно, когда есть возможность посмотреть во что вычисляется любое выражение или только что написанная функция.

Работа с REPL в целом аналогична работе в популярных математических пакетах типа Matlab и Mathematica и является вообще огромным плюсом функционального подхода.


Выбирал исключительно те варианты, которые доступны под Windows -- не держу дома Линукс из экономии времени. Кроме того, учитывал распространенность диалекта, объем документации и примеров, а также размер community.

В итоге я рассматривал 5 вариантов конфигурации Лиспа и редактора.




Common Lisp + emacs + SLIME.

Это одна из стандартных и широко распространенных связок; я начал с нее.

Среди плюсов этого подхода:


Основным аругментом "за" был тот факт, что почти все диалекты и реализации Лиспов поддерживают работу с Emacs.

Вкратце: эта конфигурация для задач быстрого старта себя не оправдала нисколько.

Не буду описывать весь процесс настройки и конфигурирования; история нисколько не более захватывающая, чем рассказ на тему "как я поутру уронил ключи от сейфа в мусоропровод и как мне к вечеру удалось их там отыскать в районе второго этажа". Скажу только, что Emacs в связке со SLIME относится к наихудшей -- в плане легкости установки и настройки -- категории Open Source: "работает только с помощью лома и такой-то матери". Основные проблемы заключаются в поддержке совместимости между разными версиями Emacs, SLIME, Лиспа и ОС. Был ошарашен безалаберностью (граничащей с вредительством), с которой эта поддержка реализуется в конфигурационных скриптах SLIME. В некоторых случаях выбирается наихудшее решение из возможных.

Итого, связка Лисп + Emacs мне представляется злом по следующим причинам:
-- дьявольски неудобная настройка;
-- необходимость в нагрузку к Лиспу разбираться еще и в редакторе Emacs (Вы ведь не редакторами интересуетесь, а функциональными языками, не так ли?);
-- удобство использования Emacs также вопрос дискуссионный: хотя его адепты и обещают златые горы, по результатам анализа эти горы сделаны совсем из другого материала (есть мнение, что это какая-то органика ): набор фич хотя и богатый, но ничего блистательного в них нету, а эзотерические клавиатурные комбинации поначалу сильно осложнят жизнь.

В общем, Лисп + Emacs -- это слишком круто для начала, причем не из-за Лиспа, а из-за Emacs. Вы рискуете никогда не приступить к собственно программированию, погрязнув в настройках редактора. Причем не с целью приспособить его под себя, а просто чтоб заставить его работать.

Совершенно нормальным вариантом представляется переход под Emacs уже после освоения Лиспа; тогда кривая обучения будет не слишком крута.

Встречаются утверждения такого рода: "Все используют Лисп исключительно вместе emacs, и было бы глупо использовать что-то другое." Это, разумеется, неправда: не все, не исключтельно и не глупо. Приведенный PR-прогруз принадлежит emacs-фанатикам, да гореть им в аду навеки .

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

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



Lisp in a Box

Это на самом деле тоже Лисп + Emacs, но позиционируется как предназначенный для начинающих. По замыслу авторов, дистрибутив должен избавить пользователя от кошмаров, свойственных предыдущему варианту конфигурации, за счет продуманных и доработанных настроек. Именно на этом свойстве дистрибутива делается основной акцент. В "Box" включен набор примеров из замечательной книги "Practical Common Lisp". В документации утверждается, что все должно заработать с полпинка, безо всякой настройки и без скачивания дополнительных компонент.

Ничего подобного: дополнительные компоненты скачивать пришлось, настройка потребовалась, с первого раза ничего не заработало. Хотя, конечно, довести Lisp in a Box до рабочей конфигурации несравненно легче, чем связку Лисп + Emacs.

Кроме того, находящиеся в Box-е реализации лиспов слегка подустарели, а для Windows их доступно всего две. Причем нужно сделать выбор "или-или"; обе реализации так вот запросто установить не удастся.

Итого: работать с этим можно, но от Emacs и от проблем конфигурирования тоже никуда не деться. Хотя масштаб этих проблем на порядок меньше.



Jaberwoocky

По-нашему говоря, Бармаглот. Проект "Бармаглот" -- вполне достойная попытка создать полноценную бесплатную IDE для Лиспа. Заявленный набор фич редактора почти такой же, как у Visual Studio; кроме того, есть REPL и интеграция с отладчиком.

Была выпущена стабильная версия 1.0 и бранч 2.0 (альфа-версия). Разработка остановилась в начале 2000-х, а полностью прекращена в 2004 году.

Эти обстоятельства удержали меня от того, чтобы вступить в бой с бармаглотом.

Наверное, это как-то работает. Но из соображений экономии времени лучше не проверять.



ABLE

ABLE означает A Basic Lisp Editor. Довольно свежий и развивающийся проект.

Не является IDE: не поддерживает "проекты", "Solutions" и т.п.
Как редактор реализует REPL, подсветку синтаксиса и расстановку отступов, настраиваемую помощь.

Установка и настройка заняли около 10 минут; усе заработало сразу. Чтения документации по редактору не требуется. Несмотря на минимализм, позволяет дорабатывать себя напильником, но этого совершенно не требуется. Легко интегрируется с ситемой сборки ASDF.

Минусы: опирается исключительно на реализацию CLisp, хотя и довольно свежую.

Является идеальным вариантом для изучения Common Lisp.



PLT Scheme

Scheme -- это диалект Лиспа, довольно далеко отошедший от Common Lisp.
В варианте PLT Scheme + DrScheme без проблем настраивается и работает, предоставляя нормальную IDE, хорошо проработанную документацию и набор учебных примеров.

PLT Scheme является идеальным вариантом для изучения Scheme. Но не для Common Lisp. PLT Scheme стоит брать, если стоит задача изучить основные концепции и отложить Лисп в сторону. Именно для такой цели этот язык и был разработан.


Что касается конкретной реализации Лиспа, здесь в равной степени распространены следующие экземпляры:


У меня сложилось впечатление, что для начала годится любой из них.





Итого:

    не начинайте со связки Lisp + Emacs -- это больно;

    чтобы быстро освоиться в Common Lisp, берите ABLE, если вам нужен Scheme -- берите PLT Scheme;

    выбор конкретной реализации Common Lisp для начала значения не имеет.




To be continued...
Тот, кто желает, но не делает, распространяет чуму.
Re: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор верси
От: DemAS http://demas.me
Дата: 09.03.09 14:42
Оценка:
> Дело в том, что от редактора Лиспа требуется больше, чем просто
> синтаксическая подсветка текста. Редактор должен реализовывать
> Read-Eval-Print Loop (коротко REPL), или попросту говоря, возможность
> интерактивного исполнения пользовательского ввода.

А можно поподробнее — что такое REPL?

Я правильно понимаю, что весь REPL сводится к тому, что в редакторе кода
есть два окна? В одном (implementation) мы пишем код, например, функции, а
в другом (аналог командной строки) мы можем тут же эту сроку протестировать.

А в чем тогда революционность подхода? С таким же успехом я могу открыть
текстовый редактор с кодом Python/Ruby/Lisp и консоль рядом с запущенным
интерпретатором.

> PLT Scheme является идеальным вариантом для изучения Scheme. Но не для Common Lisp. PLT Scheme стоит брать, если стоит задача изучить основные концепции и отложить Лисп в сторону. Именно для такой цели этот язык и был разработан.


Хм... почему? В Scheme есть достаточно много библиотек для работы с web,
файлами, базами данных. У guile есть привязки к gtk.
Posted via RSDN NNTP Server 2.1 beta
Re[2]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: volk  
Дата: 09.03.09 15:20
Оценка:
Здравствуйте, DemAS, Вы писали:

DAS>А можно поподробнее — что такое REPL?

Wiki.

DAS>А в чем тогда революционность подхода?

Ни в чем. REPL для интерпретируемого языка -- это норма, утвердившаяся еще во времена BASIC-а. Впрочем, REPL для компилируемого языка -- это уже не так привычно.

DAS>С таким же успехом я могу открыть

DAS>текстовый редактор с кодом Python/Ruby/Lisp и консоль рядом с запущенным
DAS>интерпретатором.

The term REPL is most usually used to refer to a Lisp interactive environment, but can be applied to command line shells and similar environments for Smalltalk, Python, Ruby, Haskell, APL, BASIC, J, Scheme, TCL, and other languages as well.

Wiki



>> PLT Scheme является идеальным вариантом для изучения Scheme. Но не для Common Lisp. PLT Scheme стоит брать, если стоит задача изучить основные концепции и отложить Лисп в сторону. Именно для такой цели этот язык и был разработан.


DAS>Хм... почему? В Scheme есть достаточно много библиотек для работы с web,

DAS>файлами, базами данных. У guile есть привязки к gtk.

Да, это все правда, библиотеки весьма богаты. Но все-таки основной импульс развитию Scheme придает его использование в качестве первого языка в ряде университетов. Это в первую очередь учебный язык, основные его потребители -- undergrad's, и ими же написана значительная часть библиотек.
Тот, кто желает, но не делает, распространяет чуму.
Re[3]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: DemAS http://demas.me
Дата: 09.03.09 15:42
Оценка:
"volk" <2720@users.rsdn.ru> writes:

> Wiki.


Угу, значит я правильно понял.

>

> The term REPL is most usually used to refer to a Lisp interactive environment, but can be applied to command line shells and similar environments for Smalltalk, Python, Ruby, Haskell, APL, BASIC, J, Scheme, TCL, and other languages as well.
>
> Wiki


Просто с учетом этой цитаты не совсем понятна мысль самого первого поста —
"если брать среду, то обязательно с REPL".

А если не будет в среде поддержки REPL? То мы просто открываем рядом
консоль и получаем любимый нами REPL. Получается, что поддержка REPL
редактором не так уж и важна.

p.s. Сам пользуюсь emacs, в котором есть поддержка REPL почти для всех ЯП.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: volk  
Дата: 09.03.09 16:14
Оценка:
Здравствуйте, DemAS, Вы писали:

DAS>Просто с учетом этой цитаты не совсем понятна мысль самого первого поста -

DAS>"если брать среду, то обязательно с REPL".

DAS>А если не будет в среде поддержки REPL? То мы просто открываем рядом

DAS>консоль и получаем любимый нами REPL. Получается, что поддержка REPL
DAS>редактором не так уж и важна.

Ага, если следовать этой логике, то и редактор не особо нужен. Открываем одну консоль -- это будет REPL; открываем другую, набираем copy con file.lisp -- это будет редактор.

Счастливы те, кто забыл как выглядит консоль в Windows. Среди пользователей известна под названием "Черная Дыра". Выпадет шанс с ней пообщаться -- попробуйте что-нибудь скопировать оттуда или, наборот, туда.

...Если брать среду, то только с REPL.
Тот, кто желает, но не делает, распространяет чуму.
Re[2]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: p_kolya  
Дата: 09.03.09 17:03
Оценка:
Здравствуйте, DemAS, Вы писали:

DAS>А можно поподробнее — что такое REPL?


DAS>Я правильно понимаю, что весь REPL сводится к тому, что в редакторе кода

DAS>есть два окна? В одном (implementation) мы пишем код, например, функции, а
DAS>в другом (аналог командной строки) мы можем тут же эту сроку протестировать.

Не совсем правда. Например, в emacsе можно в одном буфере(окне) писать код, тут же его исполнять поблочно, получать результаты, а потом нужно лишь сохранить буфер и будет готовый код (если вы чистили его от ошибок, конечно). Действительно очень удобно.
Re[5]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: z00n  
Дата: 09.03.09 17:25
Оценка:
Здравствуйте, volk, Вы писали:

V>Счастливы те, кто забыл как выглядит консоль в Windows. Среди пользователей известна под названием "Черная Дыра". Выпадет шанс с ней пообщаться -- попробуйте что-нибудь скопировать оттуда или, наборот, туда.

ALT-SPACE E (K Y P), а если мышь не нужна — то мышью.

Но, конечно, лучшая консоль под win — cygwin bash внутри emacs:
Re: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор верси
От: Pirsig  
Дата: 09.03.09 17:37
Оценка: 1 (1)
Здравствуйте, volk, Вы писали:

V> Common Lisp + emacs + SLIME.


V>Это одна из стандартных и широко распространенных связок; я начал с нее.

V>Вкратце: эта конфигурация для задач быстрого старта себя не оправдала нисколько.
Проблемы, наверное, связаны с тем, что все происходило на Windows.

Изучал Лисп на этой конфигурации. На Линуксе все поставилось и запустилось без проблем.
При этом на тот момент имел минимальные познание в Линуксе. Для того, чтобы начать программировать в
emacs оказалось достаточным прочитать tutorial. Не скажу, что это дружелюбная к новичку среда,
но я постепенно втянулся, а потом и понравилось.
Re: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор верси
От: z00n  
Дата: 09.03.09 17:37
Оценка: +3
Здравствуйте, volk, Вы писали:


V>-- удобство использования Emacs также вопрос дискуссионный: хотя его адепты и обещают златые горы, по результатам анализа эти горы сделаны совсем из другого материала (есть мнение, что это какая-то органика ): набор фич хотя и богатый, но ничего блистательного в них нету, а эзотерические клавиатурные комбинации поначалу сильно осложнят жизнь.

Я, знаете, не менее трех раз пытался(безуспешно) освоить VIM — но мне и в голову не придет сравнивать его с дерьмом.

V>Ничего подобного: дополнительные компоненты скачивать пришлось, настройка потребовалась, с первого раза ничего не заработало. Хотя, конечно, довести Lisp in a Box до рабочей конфигурации несравненно легче, чем связку Лисп + Emacs.

Я, в прошлом, ставил не менее двух раз — все работало сразу

V>Кроме того, находящиеся в Box-е реализации лиспов слегка подустарели, а для Windows их доступно всего две. Причем нужно сделать выбор "или-или"; обе реализации так вот запросто установить не удастся.

Подустарели? Стандарт вышел в 87 году

V> PLT Scheme стоит брать, если стоит задача изучить основные концепции и отложить Лисп в сторону. Именно для такой цели этот язык и был разработан.

Вы ни хрена в этом не понимаете — зачем пишете?
Re[6]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: volk  
Дата: 09.03.09 17:59
Оценка:
Здравствуйте, z00n, Вы писали:

V>>Счастливы те, кто забыл как выглядит консоль в Windows. Среди пользователей известна под названием "Черная Дыра". Выпадет шанс с ней пообщаться -- попробуйте что-нибудь скопировать оттуда или, наборот, туда.

Z>ALT-SPACE E (K Y P), а если мышь не нужна — то мышью.

Не работает.
Мышью в консоль -- не кузявно.

Z>Но, конечно, лучшая консоль под win — cygwin bash внутри emacs:

Z>

К сожалению, это правда.
Тот, кто желает, но не делает, распространяет чуму.
Re[2]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: volk  
Дата: 09.03.09 18:05
Оценка:
Здравствуйте, Pirsig, Вы писали:

P>Проблемы, наверное, связаны с тем, что все происходило на Windows.


Именно с этим, я же вроде так и писал...?

В порядке увеличения ужасти:
1) emacs (равно как vim) для Linux -- вполне органично;
2) emacs Windows -- жить можно;
3) emacs + разнообразные надстройки, разработанные для линукса и криво портированные под Win -- ну совсем плохо.
Тот, кто желает, но не делает, распространяет чуму.
Re[3]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: DemAS http://demas.me
Дата: 09.03.09 18:42
Оценка:
"volk" <2720@users.rsdn.ru> writes:

> 3) emacs + разнообразные надстройки, разработанные для линукса и криво

> портированные под Win -- ну совсем плохо.

Кстати, я тоже не понял в чем здесь проблема?
У меня на флешке конфиги emacs без изменения работают под windows и linux.
Кстати, это же относится и к vim.
Posted via RSDN NNTP Server 2.1 beta
Re[3]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: DemAS http://demas.me
Дата: 09.03.09 18:42
Оценка:
"p_kolya" <35326@users.rsdn.ru> writes:

> Не совсем правда. Например, в emacsе можно в одном буфере(окне) писать

> код, тут же его исполнять поблочно, получать результаты, а потом нужно
> лишь сохранить буфер и будет готовый код (если вы чистили его от ошибок,
> конечно). Действительно очень удобно.

Перефразирую.

Я могу открыть консоль, запустить там нужную мне среду
(python/ruby/scheme), писать там код. А потом скопировать содержимое
консоли в файл. А еще лучше сделать так, чтобы консоль сама все писала в
файл.

Не подумай, я сам emacs пользую, но никак не пойму почему все так хвалят REPL.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: Курилка Россия http://kirya.narod.ru/
Дата: 09.03.09 18:49
Оценка:
Здравствуйте, DemAS, Вы писали:

DAS>"p_kolya" <35326@users.rsdn.ru> writes:


>> Не совсем правда. Например, в emacsе можно в одном буфере(окне) писать

>> код, тут же его исполнять поблочно, получать результаты, а потом нужно
>> лишь сохранить буфер и будет готовый код (если вы чистили его от ошибок,
>> конечно). Действительно очень удобно.

DAS>Перефразирую.


DAS>Я могу открыть консоль, запустить там нужную мне среду

DAS>(python/ruby/scheme), писать там код. А потом скопировать содержимое
DAS>консоли в файл. А еще лучше сделать так, чтобы консоль сама все писала в
DAS>файл.

DAS>Не подумай, я сам emacs пользую, но никак не пойму почему все так хвалят REPL.


В консоли REPL, например, ты можешь делать "тестовые" вычисления, такие какие тебе взбредут в голову, посмотреть результаты (а в GHCi ещё и типы), поменять решение, сделать другие тесты и т.д. до получения результата, который бы тебя удовлетворял. Плюсом является минимизация REPL именно как "loop", как ты будешь делать такое в отдельных окнах и файлах — хотелось бы посмотреть, ну и замерять накладные расходы на разные переключения окон, контекстов и т.п.
Re[2]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: MasterZiv СССР  
Дата: 09.03.09 19:12
Оценка:
DemAS пишет:

> А в чем тогда революционность подхода? С таким же успехом я могу открыть

> текстовый редактор с кодом Python/Ruby/Lisp и консоль рядом с запущенным
> интерпретатором.

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

Вот у меня тут сервак работает, я его находу правлю, заливаю
и он меняется.

Это, правда, достоинство не столько репла, сколько других особенностей
языка.
Posted via RSDN NNTP Server 2.1 beta
Re[4]: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор ве
От: MasterZiv СССР  
Дата: 09.03.09 19:14
Оценка:
DemAS пишет:

> Не подумай, я сам emacs пользую, но никак не пойму почему все так хвалят

> REPL.

> (not (eq 'REPL 'CONSOLE))


T
Posted via RSDN NNTP Server 2.1 beta
Re: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор верси
От: MasterZiv СССР  
Дата: 09.03.09 19:18
Оценка: +1
volk пишет:

> В итоге я рассматривал 5 вариантов конфигурации Лиспа и редактора.

>
> -- распространенная связка Common Lisp + emacs/xemacs + SLIME
> (пакет для Emacs, реализующий REPL);

> -- Lisp in a Box <http://www.gigamonkeys.com/book/lispbox/&gt;,

> который поставляется вместе с книжкой Practical Common Lisp;

Это практически то же самое, что и первое.

> -- Jaberwoocky <http://jabberwocky.sourceforge.net/&gt;;

Jaberwoocky сдох и посмертно был страшен и глючен. И ещё на яве.

> -- Scheme <http://schemers.org/&gt; в версии PLT Scheme

> <http://www.plt-scheme.org/&gt;;

А при чём тут схема ? Вы уж разделяйте лисп (комон лисп) и схему.
Схема -- это схема. Другой язык.
Posted via RSDN NNTP Server 2.1 beta
Re: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор верси
От: MasterZiv СССР  
Дата: 09.03.09 19:19
Оценка:
volk пишет:

> Я стартовал с изучения традиционного Лиспа и теперь попытаюсь описать


Я только хочу напомнить, что Лисп ни в коем случае не является языком
функционального программирования в том смысле, в котором многие
этот термин воспринимают. А именно, он не является
чисто функциональным языком программирования. Т.е. допускает
побочные эффекты, т.е. императивный стиль.

Поэтому Лисп надо называть мультипарадигменным языком.
Posted via RSDN NNTP Server 2.1 beta
Re: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор верси
От: MasterZiv СССР  
Дата: 09.03.09 19:34
Оценка: 8 (1)
volk пишет:

>

> не начинайте со связки Lisp + Emacs -- это больно;
>
> чтобы быстро освоиться в Common Lisp, берите ABLE, если вам нужен
> Scheme -- берите PLT Scheme;
>
> выбор конкретной реализации Common Lisp для начала значения не имеет.
>

Тьфу ты, вот же память, хотел же написать, собственно, начал с этого.

Кроме всего вышеперечисленного есть написанный дла Eclipse
front-end для SLIME/SWANK, называемый CUSP. Т.е. говоря языком
простых людей, есть eclipse plug-in для Common LISP.

Живёт здесь:

http://cusp.devjavu.com/

и здесь:

http://groups.google.com/group/cusp-development

И он теперь вполне работоспособен, и кроссплатформен. Но не лишён
определённых недостатков, поскольку всё, в нём написанное, не полностью
работает, и он поставляется с определённой версией SLIME и определённой
версией SBCL (20 кажется на сей момент), и работает только с ними.

К тому же он уже включает пакет из модных библиотек для лиспа,
тоже определённых версий, но не понятно каких, средство описания систем
ASDF, и в последней версии — систему unit-тестирования lisp-unit, не
самую, надо сказать, мощную.

Неудобен он тем, что очень много на себя берёт, типа чтобы сделать
автоматом, поэтому работает он НЕ ТАК, как написано во всех FAQ,
документациях и прочее. Но чтобы понять, как он работает, нужно
приложить достаточно много усилий, если не знаешь, как это работает
изнутри.

Есть и ещё один плагин для Eclipse, одуванчик, dentdelion то бишь.
Мёртвый.

Поэтому я бы переиначил в итоге фразу
"не начинайте со связки Lisp + Emacs -- это больно" на
"начинайте со связки Lisp + Emacs -- это СТАНДАРТНО и работает."

По этому написано много материала, есть видео презентации и т.п.
и ТАМ ВСЁ РАБОТАЕТ.

Я сам начинал именно с CUSP (не, на самом деле сначала был LispWorks)

А, кстати, есть ещё 2 персональные версии промышленных lisp-ов со своими
IDE, это LispWorks и Allegro Common LISP от Franc inc.
Они для целей изучения и вхождения вполне пригодны.
Posted via RSDN NNTP Server 2.1 beta
Re: [Lisp] Отчет о первом подходе к снаряду. ч.1:Выбор верси
От: MasterZiv СССР  
Дата: 09.03.09 19:44
Оценка:
volk пишет:


Скажу только, что Emacs в связке со
> SLIME относится к наихудшей -- в плане легкости установки и настройки --
> категории Open Source: "работает только с помощью лома и такой-то
> матери". Основные проблемы заключаются в поддержке совместимости между
> разными версиями Emacs, SLIME, Лиспа и ОС. Был ошарашен безалаберностью

Согласен, что это не очень просто. Но есть много материала, как это сделать,
в отличие, напр., аналогичного про CUSP.

и есть маленький секрет, который нужно знать:
надо работать с последней версией SLIME из репозитория, НЕ С ДИСТРИБУТИВОМ,
и регулярно его обновлять. И также -- лучше с последней версией
SBCL. Вроде бы SBCL и SLIME интенсивно друг под друга затачиваются.
Posted via RSDN NNTP Server 2.1 beta
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.