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

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

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


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

---

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

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

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

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

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


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

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

-- распространенная связка Common Lisp + emacs/xemacs + SLIME (пакет для Emacs, реализующий REPL);
-- Lisp in a Box, который поставляется вместе с книжкой Practical Common Lisp;
-- Jaberwoocky;
-- Able;
-- Scheme в версии PLT Scheme;

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 стоит брать, если стоит задача изучить основные концепции и отложить Лисп в сторону. Именно для такой цели этот язык и был разработан.


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

-- CLisp;
-- GNU CLisp;
-- Allegro;
-- SBCL;
-- CMUCL.

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





Итого:

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

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

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

---

To be continued...

Поздравляю Вас с неудачным стартом.

1. REPL возможно лучше чем набирать текст в notepad и потом его запускать (хотя не факт).
2. REPL это именно Real Eval Print Loop. Аналогично командной строке DOS. И к редакторам он имеет очень посредственное отношение (хотя в некоторые из них он встроен как дополнительная фича).
3. REPL (мое сугубо личное мнение) это один из самых убогих подходов. Он видимо был актуален тогда, когда при продаже овец каждую овцу ставили рядом с кусочком золота (т.к. считать не умели). Но на дворе уже 2009 год.
4. По крайней мере для Common LISP ничего лучше Slime не придумали. В Slime есть REPL, но я ни разу им не пользовался из-за ненадобности. Зато там есть Масса полезных фич, что действительно облегчают написание софта на Common LISP. Это почти что Eclipse, но не для Java а для LISP. Да, Emacs для многих не подарок. Я тоже от него не тащусь и считаю что конфигурировать его это не самое приятное времяпровождение. Но пока (по крайней мере для CL) ничего лучше чем Slime не видел. Даже коммерческие IDE типа той что в LispWorks уже не нравятся. :-)

volk пишет:

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

Короче, автор, продолжай пожалуйста, а то они тут ещё 3 года будут
спорить, хорошо ли REPL или плохо.

Здравствуйте, volk, Вы писали:


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

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

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

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

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.
Они для целей изучения и вхождения вполне пригодны.

Здравствуйте, volk, Вы писали:

V> Common Lisp + emacs + SLIME.

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

Изучал Лисп на этой конфигурации. На Линуксе все поставилось и запустилось без проблем.
При этом на тот момент имел минимальные познание в Линуксе. Для того, чтобы начать программировать в
emacs оказалось достаточным прочитать tutorial. Не скажу, что это дружелюбная к новичку среда,
но я постепенно втянулся, а потом и понравилось.

saturas пишет:
> Большое спасибо. А что скажите насчет коммерческих решений (как и было
> освящено в статье, с точки зрения быстрого старта)? Allegro вроде имеет

Я могу сказать на счёт этого. Я начинал изучать лисп на LispWorks.
В общем, достаточно удобная среда, если её ещё и подкрутить немного
под свои нужны (на родном их сайте много подкруток от третьих лиц).

Редактор наследник Hemlock-а, т.е. emacs-подобный. Но без
сложных наворотов. В общем, аналог SLIME-а по функциональности.

Из ограничений персональной эдиции -- невозможность сохранения
образа и невозможность работы в одном образе более (кажется) 2-3
часов. Надо будет перегружаться. В остальном — всё достаточно
красиво, симпатично и понятно.

Аллегру персонал не смотрел.

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;;

А при чём тут схема ? Вы уж разделяйте лисп (комон лисп) и схему.
Схема -- это схема. Другой язык.

Здравствуйте, Аноним, Вы писали:
А>Теперь объясняйте, где я идиот.
Тут.
А>стоит использовать, если стоит задача изучить основные концепции и по завершении обучения отложить в сторону.

Scheme — весьма удачный непромышленный язык. На нем удобно решать небольшие задачи.
Это если отложить в сторону то, что существует ряд крупных проектов на scheme (например, в plt много кода на scheme).

В целом, схемеры возмущены тем, что тема scheme затронута, но совершенно не раскрыта. Ни в плане средств разработки (например, для emacs есть quack, есть scheme way для eclipse и т.п.), ни в плане имплементаций (которых вагон и маленькая тележка).

Ну а тем, кто нацелен на CL, Ваш труд наверняка будет полезен — да.

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

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

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

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

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

Хм... почему? В Scheme есть достаточно много библиотек для работы с web,
файлами, базами данных. У guile есть привязки к gtk.

Здравствуйте, 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, и ими же написана значительная часть библиотек.

"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 почти для всех ЯП.

Здравствуйте, DemAS, Вы писали:

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

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

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

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

...Если брать среду, то только с REPL.

Здравствуйте, DemAS, Вы писали:

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

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

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

Здравствуйте, volk, Вы писали:

V>Счастливы те, кто забыл как выглядит консоль в Windows. Среди пользователей известна под названием "Черная Дыра". Выпадет шанс с ней пообщаться -- попробуйте что-нибудь скопировать оттуда или, наборот, туда.
ALT-SPACE E (K Y P), а если мышь не нужна — то мышью.

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

Здравствуйте, z00n, Вы писали:

V>>Счастливы те, кто забыл как выглядит консоль в Windows. Среди пользователей известна под названием "Черная Дыра". Выпадет шанс с ней пообщаться -- попробуйте что-нибудь скопировать оттуда или, наборот, туда.
Z>ALT-SPACE E (K Y P), а если мышь не нужна — то мышью.

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

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

К сожалению, это правда.

Здравствуйте, Pirsig, Вы писали:

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

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

В порядке увеличения ужасти:
1) emacs (равно как vim) для Linux -- вполне органично;
2) emacs Windows -- жить можно;
3) emacs + разнообразные надстройки, разработанные для линукса и криво портированные под Win -- ну совсем плохо.

"volk" <2720@users.rsdn.ru> writes:

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

Кстати, я тоже не понял в чем здесь проблема?
У меня на флешке конфиги emacs без изменения работают под windows и linux.
Кстати, это же относится и к vim.

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

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

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

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

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

Здравствуйте, 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", как ты будешь делать такое в отдельных окнах и файлах — хотелось бы посмотреть, ну и замерять накладные расходы на разные переключения окон, контекстов и т.п.

DemAS пишет:

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

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

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

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

DemAS пишет:

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

> (not (eq 'REPL 'CONSOLE))

T

volk пишет:

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

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

Поэтому Лисп надо называть мультипарадигменным языком.

volk пишет:


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

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

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

volk пишет:

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

Да, ещё, EMACS — обязательно 22 или выше !!

для "опасающихся" там уже есть поддержка стандарта CUI.
Если совсем хочется как на винде, есть ещё pcmode, специальная
примочка, которая делает выделение и копирование таким же, как в винде.

Здравствуйте, z00n, Вы писали:

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

Если бы я хотел назвать emacs дерьмом, я бы так и сделал.
Уточню свою позицию.
Считаю, что с emacs-ом можно работать. Не вижу смысла начинать разбираться одновременно с emacs и с Lisp (тем более из-под Windows). Вижу смысл в том, чтобы разбираться с ними последовательно. Вопрос "нужен ли мне emacs" для себя решил отрицательно.

(Замечу, что освоил vi в старших классах школы, потому что на тех машинах не было других редакторов; что я делал не так?)



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

Проверил установкой на относительно чистую машину (ноут) -- действительно, работает без напильника. Согласен, здесь я болван, вот только не понял, где именно. Реализация лиспа в Box-е, тем не менее, не самая свежая -- подустарела.


Z>Подустарели? Стандарт вышел в 87 году
В 87 году стандарт только "начал выходить". А вышел (опубликован) этот аленький цветочек к середине 90-х. С тех пор выдано на гора чуть ли не полсотни релизов CLisp-а. Та версия, которая входит в LiaB сейчас, отстает от текущей на три года и более чем на 10 релизов. Три года, 10 релизов -- это я и называю "подустарели".



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

Я, возможно, ни хрена не понимаю в Схеме, особенно супротив опытного схемера. Однако пою, что вижу.

А вижу следующее.

Common Lisp	Scheme
Цель разработки и развития
Консолидация Лиспов	Исследования, обучение
Платформы
Много (включая sparc, arm, powerpc и т.п.)	nix, win, OS/2, JIT
Killer Applications
Пара штук найдется	?
Стандартная библиотека
Есть	Нет
Многоядерность
Реализована	Нет(?)
Во сколько раз медленнее C/С++	(Computer Lang. Bench. Game)
2-10	5-100
Числодробление
Полноценный GNU GSL	Разрозненные библиотеки
Общее впечатление
Старый матерый бегемот	Элегантно-минималистичный новодел

В общем, Lisp vs Scheme -- это как C vs Современный Pascal.


И про Паскаль, и про Scheme в этом контексте я бы сказал одинаково:

стоит использовать, если стоит задача изучить основные концепции и по завершении обучения отложить в сторону.



Теперь объясняйте, где я идиот.

Это был я.

Здравствуйте, Аноним, Вы писали:

А>Я, возможно, ни хрена не понимаю в Схеме, особенно супротив опытного схемера. Однако пою, что вижу.

А>А вижу следующее.
А>
А>
А>
А>

А>
А>

А>
А>

А>
А>
А>
А>
А>
А>
А>
А>
А>
А>
А>

Common Lisp	Scheme
Цель разработки и развития
Консолидация Лиспов	Исследования, обучение
Платформы
Много (включая sparc, arm, powerpc и т.п.)	nix, win, OS/2, JIT
Killer Applications
Пара штук найдется	?
Стандартная библиотека
Есть	Нет
Многоядерность
Реализована	Нет(?)
Во сколько раз медленнее C/С++	(Computer Lang. Bench. Game)
2-10	5-100
Числодробление
Полноценный GNU GSL	Разрозненные библиотеки
Общее впечатление
Старый матерый бегемот	Элегантно-минималистичный новодел

Я не знаю где вы взяли эту таблицу — но к ней претензии те-же. Новодел Scheme примерно ровесник С (72 и 75 годы). Если это не вы ее составили, то совет — не читайте что попало (особенно на русском).
Вот например, что написал на эту тему автор "Practical Common Lisp": http://www.mail-archive.com/gardeners@lispniks.com/msg01671.html


А>В общем, Lisp vs Scheme -- это как C vs Современный Pascal.
В общем хрень

А>И про Паскаль, и про Scheme в этом контексте я бы сказал одинаково:
А>стоит использовать, если стоит задача изучить основные концепции и по завершении обучения отложить в сторону.
Лихо обобщаете.

А>Теперь объясняйте, где я идиот.
Я не говорил, что вы идиот. Я лишь выразил сожаление по поводу вашего труда. Вы написали интересный, полезный пост — и зачем-то щедро разбавили его непроверенной информацией о том, в чем сами не разбираетесь. Труд насмарку

Здравствуйте, MasterZiv, Вы писали:

MZ>А, кстати, есть ещё 2 персональные версии промышленных lisp-ов со своими
MZ>IDE, это LispWorks и Allegro Common LISP от Franc inc.
MZ>Они для целей изучения и вхождения вполне пригодны.

Есть еще Corman Lisp, но кажется только для Windows. У меня Allegro CL, но мне жутко не нравится его IDE, я использую как раз связку Emacs + SLIME.

Здравствуйте, MasterZiv, Вы писали:

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

MZ>и есть маленький секрет, который нужно знать:
MZ>надо работать с последней версией SLIME из репозитория, НЕ С ДИСТРИБУТИВОМ,
MZ>и регулярно его обновлять.

MZ>И также -- лучше с последней версией
MZ>SBCL. Вроде бы SBCL и SLIME интенсивно друг под друга затачиваются.

MZ>Да, ещё, EMACS — обязательно 22 или выше !!

MZ>для "опасающихся" там уже есть поддержка стандарта CUI.
MZ>Если совсем хочется как на винде, есть ещё pcmode, специальная
MZ>примочка, которая делает выделение и копирование таким же, как в винде.

Эти, без шуток, ценные рекомендации что-то мне напоминают.

Извините, не смог удержаться:

Разом все вокруг котла!
Сыпьте скверну в глубь жерла!
Жаба, меж сырых камней
Тридцать семь ночей и дней
Ядом превшая во сне,
Раньше всех варись на дне.

Мясо трех болотных змей,
Разварись и разопрей;
Пясть лягушки, глаз червяги,
Шерсть ушана, зуб дворняги,
Жало гада, клюв совенка,
Хвост и лапки ящеренка —
Для могущественных чар
Нам дадут густой навар.

Жарко, жарко, пламя ярко!
Хороша в котле заварка!

Кровь павьяна вар остудит,
И тогда все прочно будет.

Здравствуйте, Pirsig, Вы писали:

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

В первую очередь — проблемы у автора с головой.
Да, под виндой со всем этим "хозяйством" на порядок хуже (в том плане что "автоматом" и "из коробки" действительно мало что работает)
Но большинство проблем разжёвано в куче мест и решается элементарно.
А сам по себе набор "emacs+(any)CL настолько прост, что втягиваешься очень быстро и уже через несколько недель начинаешь слать патчи =)

P.S. Да, сначала надо отдавать себе отчёт что emacs очень сильно отличается от большинства редакторов, известных большинству кодеров

Здравствуйте, volk, Вы писали:
V>Эти, без шуток, ценные рекомендации что-то мне напоминают.

Зря Вы так. В emacs 23 (или какая там версия в cvs) под линуксом у меня сразу завелось сглаживание шрифтов и русский язык, чего до этого не наблюдалось. Так что чем новее emacs — тем лучше. Ну а sbcl — одна из лучших открытых имплементаций cl.

Здравствуйте, Аноним, Вы писали:
А>А вижу следующее.
А>Таблица поскипана

Таблица больше забавная, чем информативная (чего только стоят архитектуры процессоров в графе "платформы" у cl и операционные системы в той же графе у scheme).

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>3. REPL (мое сугубо личное мнение) это один из самых убогих подходов. Он видимо был актуален тогда, когда при продаже овец каждую овцу ставили рядом с кусочком золота (т.к. считать не умели). Но на дворе уже 2009 год.

То то я вижу REPL для C# 4-го тока тока появиться, когда на дворе 2009-й год... Надо Хейлсбергу сказать, мол нынче не актуальная фишка этот repl, мол 2009-й год на дворе...

cl-user пишет:

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

Да нифига подобного. Проблемы у меня были только с самим SBCL-ем,
с его функциональностью. Все остальное — Emacs, SLIME — без проблем
и под виндой, я дольше постигал, в чём разница между Emacs и XEmacs,
чем ставил и конфигурил SLIME.

Аноним 6 пишет:
> В общем, Lisp vs Scheme -- это как C vs Современный Pascal.

Скорее, ровно наоборот.

CommonLisp — промышленный, развитой язык. Но большой и более сложный,
по сравнению со схемой. Схема — маленькая, элегантная и простая. Но
скорее для пром. программирования не предназначенная (хотя из меня такой
спец по схеме, что ойойой... )

И главное -- там разные идеологические направления развития лисп-образных
языков конденсировались.

Mr.Cat пишет:

> Зря Вы так. В emacs 23 (или какая там версия в cvs) под линуксом у меня
> сразу завелось сглаживание шрифтов и русский язык, чего до этого не
22 должно быть. С 22 версии с русским стало всё ОК, вот ДО были действительно
тапки.

Rtveliashvili Denys пишет:

> 2. REPL это именно Real Eval Print Loop. Аналогично командной строке
> DOS. И к редакторам он имеет очень посредственное отношение (хотя в
> некоторые из них он встроен как дополнительная фича).

REPL == READ, EVALUATE and PRINT LOOP.

Здравствуйте, MasterZiv, Вы писали:

MZ>Rtveliashvili Denys пишет:

>> 2. REPL это именно Real Eval Print Loop. Аналогично командной строке
>> DOS. И к редакторам он имеет очень посредственное отношение (хотя в
>> некоторые из них он встроен как дополнительная фича).

MZ>REPL == READ, EVALUATE and PRINT LOOP.

Да, да. Очепятался с утра. Read, Evaluate, Print, Loop.

RD>>3. REPL (мое сугубо личное мнение) это один из самых убогих подходов. Он видимо был актуален тогда, когда при продаже овец каждую овцу ставили рядом с кусочком золота (т.к. считать не умели). Но на дворе уже 2009 год.

Y>То то я вижу REPL для C# 4-го тока тока появиться, когда на дворе 2009-й год... Надо Хейлсбергу сказать, мол нынче не актуальная фишка этот repl, мол 2009-й год на дворе...

Здорово! Специально для Вас в C# сделали REPL. Кстати.. Наверное все-таки не в самом C# (т.к. это язык) а в Visual Studio? Или я неправильно понимаю?

Судя по тону Вашего комментария, Вы считаете что REPL это круть. Всегда хотел узнать, что именно в нем вам так нравится и почему Вам не нравится та же функциональность но встроенная непосредственно в IDE? Действительно удобно copy-paste делать между текстом программы и REPL окном?

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

V>Разнообразные фичи ФЯ здесь обсуждаться не будут.

Противоречие, нет?

Здравствуйте, MasterZiv, Вы писали:
MZ>22 должно быть.

Возможно. Я его поставил, ужаснулся шрифтам и снес от греха подальше.

Здравствуйте, Mr.Cat, Вы писали:

MC>Возможно. Я его поставил, ужаснулся шрифтам и снес от греха подальше.
Это под линухом? Там была экспериментальная сборка под GTK+, которую потом слили в 23.
Под windows, как не странно, 22 emacs имел отличную поддержку шрифтов.

Здравствуйте, z00n, Вы писали:
Z>Это под линухом?

Угу. 22-я версия из репозитория archlinux. Сейчас у меня стоит и регулярно обновляется версия из cvs — там все ок.

"MasterZiv" <30904@users.rsdn.ru> writes:

> Это, правда, достоинство не столько репла, сколько других особенностей
> языка.

Именно. Тот же Erlang позволяет заменять код "на лету". Но ему при этом
пофигу где этот код был создан — в среде поддерживающей REPL или нет.

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

Здравствуйте, MasterZiv, Вы писали:

MZ>Аноним 6 пишет:
>> В общем, Lisp vs Scheme -- это как C vs Современный Pascal.

MZ>Скорее, ровно наоборот.

MZ>CommonLisp — промышленный, развитой язык. Но большой и более сложный,
MZ>по сравнению со схемой. Схема — маленькая, элегантная и простая. Но
MZ>скорее для пром. программирования не предназначенная (хотя из меня такой
MZ>спец по схеме, что ойойой... )

Ну так я ровно это и имел ввиду.
Почему же тогда
MZ>Скорее, ровно наоборот.

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Поздравляю Вас с неудачным стартом.
Вообще-то старт был вполне удачный.

RD>3. REPL (мое сугубо личное мнение) это один из самых убогих подходов. Он видимо был актуален тогда, когда при продаже овец каждую овцу ставили рядом с кусочком золота (т.к. считать не умели). Но на дворе уже 2009 год.

И в 1980-м, и сейчас REPL все так же замечательно применяется в ряде математических пакетов. Чем предложите заменить?

Здравствуйте, thesz, Вы писали:

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

V>>Разнообразные фичи ФЯ здесь обсуждаться не будут.

T>Противоречие, нет?

Нет; я имел ввиду, что буду говорить в основном про технические моменты -- типа "как его готовить".
А монады-замыкания-продолжения и прочие чудеса оставляю вам, матерым хаскеллистам.

V>>>Если Вы только собираетесь освоить функциональный подход и выбираете язык для быстрого старта, то это сообщение будет для Вас полезным.
V>>>Разнообразные фичи ФЯ здесь обсуждаться не будут.
T>>Противоречие, нет?
V>Нет; я имел ввиду, что буду говорить в основном про технические моменты -- типа "как его готовить".
V>А монады-замыкания-продолжения и прочие чудеса оставляю вам, матерым хаскеллистам.

Я ради галочки: разговор будет вестись только о Лиспе, без сравнений с другими ЯП, так? И только технические детали, только Лиспа, так?

Исключительно ради занудства.

RD>>Поздравляю Вас с неудачным стартом.
V>Вообще-то старт был вполне удачный.

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

V>И в 1980-м, и сейчас REPL все так же замечательно применяется в ряде математических пакетов. Чем предложите заменить?

REPL позволяет выяснить, каким будет значение выражения или получить более подробную информацию о нем (тип, документация, и т.д.).
На мой вкус, все это должно быть интегрировано прямо в IDE. Пишешь себе код, и если интересно узнать что-то — жмешь shortcut. Так, кстати, сделано в Slime и (в какой-то степени) в OcaIDE.

Впрочем, я так вижу что народ к неудобствам привык (или считает это удобствами), так что ситуация врядли изменится.

К>В консоли REPL, например, ты можешь делать "тестовые" вычисления, такие какие тебе взбредут в голову, посмотреть результаты (а в GHCi ещё и типы), поменять решение, сделать другие тесты и т.д. до получения результата, который бы тебя удовлетворял. Плюсом является минимизация REPL именно как "loop", как ты будешь делать такое в отдельных окнах и файлах — хотелось бы посмотреть, ну и замерять накладные расходы на разные переключения окон, контекстов и т.п.

Интерсно, а кто-нибудь осилит таки поставить Slime и понять как он работает? Это не так сложно.

Там прямо в тексте программы пишешь что хочешь. И это что хочешь выполняешь. И не только выполняешь. И после всей этой возни тебе не надо вылавливать по истории REPL введенные когда-то выражения. Они у тебя уже в файле. Надо просто сохранить. Так что REPL _вообще_ не дает преимуществ по ставнению со средами вроде Slime.

Здравствуйте, thesz, Вы писали:

V>>>>Разнообразные фичи ФЯ здесь обсуждаться не будут.

T>Я ради галочки: разговор будет вестись только о Лиспе, без сравнений с другими ЯП, так? И только технические детали, только Лиспа, так?

в его посте — да, так и было

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>3. REPL (мое сугубо личное мнение) это один из самых убогих подходов. Он видимо был актуален тогда, когда при продаже овец каждую овцу ставили рядом с кусочком золота (т.к. считать не умели). Но на дворе уже 2009 год.

Не соглашусь, делать программу находясь прямо в ней это не забываемый опыт. Безусловно легко получить продукт который не сможет "вытащить себя за шнурки" при запуске, но заработает он быстро. И размышления при его запуске, когда каждая мысль эволюционно развивает программу и тестируется, фундаментально прочны. Да продукты так и тянет распространять в виде дампов + райнтайм. Вот например как об этих двух подходах пишет явный сторонник редактирования кода:

4.4 Philosophies for Combining S with ESS
There are two primary philosophies for using ESS. The default is that the source
code (the file ‘myfile.s’, for example) is real, and objects in S are temporary real-
izations of the source. A project is constructed by writing S language source code
for user defined functions and data objects. One or more text files containing the
code are stored in a project directory or directories. The code is read into S for
a temporary realization as an object. This approach allows for better portability,
where the user might want to use the written code and perform the same or re-
lated analyses on different versions of the S language. This approach also permits
external version control for S language source code.
The second, deprecated view, is that S objects are real. The text version of the
objects (source code, although we can’t use that term with this philosophy) is a
temporary realization of the objects. ESS is then used to edit, but not save, the
text. The text is returned to S to be saved as an object. We strongly discourage
this approach. It is a natural result of assuming that the S process will always be
the same, an assumption we are not willing to make.


На самом деле достаточно что бы было что то вроде edit(имя_редактируемого) возвращающее набранное в любимом редакторе. Комплектация есть уже везде, и в REPL она более полная чем в редакторе.

думаю Вас не смутит, что пример взят из S/R ?

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Здорово! Специально для Вас в C# сделали REPL. Кстати.. Наверное все-таки не в самом C# (т.к. это язык) а в Visual Studio? Или я неправильно понимаю?

В самом C#'е, причем тут VS вообще? Неправильно все понимаете.

RD>Судя по тону Вашего комментария, Вы считаете что REPL это круть. Всегда хотел узнать, что именно в нем вам так нравится и почему Вам не нравится та же функциональность но встроенная непосредственно в IDE? Действительно удобно copy-paste делать между текстом программы и REPL окном?

Ну не то чтобы круть, просто очень удобно, по крайней мере для меня. Где в IDE та же функциональность, я бы рад это увидеть, можешь пальцем указать? Судя по всему Вы вообще понятия не имеете, что такое REPL.

Могу рассказать свой самый частый use case. У меня обычно открыто два буфера в эмаксе, один с исходником, другой с repl'ом. Пишу в буфере с кодом какую-либо функцию, компилирую ее (функцию), затем иду в repl и пробую дергать свою функцию с разными параметрами. Пищу следующую функцию (возможно вызывающую предыдущую) и все то же самое.

Здравствуйте, yumi, Вы писали:

Y>Ну не то чтобы круть, просто очень удобно, по крайней мере для меня. Где в IDE та же функциональность, я бы рад это увидеть, можешь пальцем указать? Судя по всему Вы вообще понятия не имеете, что такое REPL.

В принципе, функциональность аналогичную REPL-у можно получить, заведя для этого отдельный unittest.
Будет примерно так, как ты и описываешь — в одном окошке пишешь, компилируешь, в другом — запускаешь.

Здравствуйте, Lloyd, Вы писали:

L>В принципе, функциональность аналогичную REPL-у можно получить, заведя для этого отдельный unittest.
L>Будет примерно так, как ты и описываешь — в одном окошке пишешь, компилируешь, в другом — запускаешь.

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

Lloyd пишет:

> В принципе, функциональность аналогичную REPL-у можно получить, заведя
> для этого отдельный unittest.

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

Здравствуйте, yumi, Вы писали:

L>>В принципе, функциональность аналогичную REPL-у можно получить, заведя для этого отдельный unittest.
L>>Будет примерно так, как ты и описываешь — в одном окошке пишешь, компилируешь, в другом — запускаешь.

Y>Не, аналогичную точно не получить,

В чем отличие?

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

Чем это лучше unittest-а?

Здравствуйте, MasterZiv, Вы писали:
MZ>Короче, автор, продолжай пожалуйста, а то они тут ещё 3 года будут

Вот тут согласен.

Здравствуйте, Lloyd, Вы писали:

L>>>В принципе, функциональность аналогичную REPL-у можно получить, заведя для этого отдельный unittest.
L>>>Будет примерно так, как ты и описываешь — в одном окошке пишешь, компилируешь, в другом — запускаешь.
Y>>Не, аналогичную точно не получить,

L>В чем отличие?

Да хотя бы тем, что в repl'е сохраняется environment.

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

L>Чем это лучше unittest-а?

Тут скорее, почему unittest? Цель unittest'ов ортогональна repl'у.

RD>>Здорово! Специально для Вас в C# сделали REPL. Кстати.. Наверное все-таки не в самом C# (т.к. это язык) а в Visual Studio? Или я неправильно понимаю?
Y>В самом C#'е, причем тут VS вообще? Неправильно все понимаете.

Аналог GHCi в Хаскере или просто запуска python без агрументов в питоне? Мрак, это еще хуже, чем я думал.
Может Вы С# код пишете в notepad? Я тоже когда-то так делал. Но не долго.

RD>>Судя по тону Вашего комментария, Вы считаете что REPL это круть. Всегда хотел узнать, что именно в нем вам так нравится и почему Вам не нравится та же функциональность но встроенная непосредственно в IDE? Действительно удобно copy-paste делать между текстом программы и REPL окном?
Y>Ну не то чтобы круть, просто очень удобно, по крайней мере для меня. Где в IDE та же функциональность, я бы рад это увидеть, можешь пальцем указать? Судя по всему Вы вообще понятия не имеете, что такое REPL.

Конечно и понятия не имею.

Y>Могу рассказать свой самый частый use case. У меня обычно открыто два буфера в эмаксе, один с исходником, другой с repl'ом. Пишу в буфере с кодом какую-либо функцию, компилирую ее (функцию), затем иду в repl и пробую дергать свою функцию с разными параметрами. Пищу следующую функцию (возможно вызывающую предыдущую) и все то же самое.

В случае с Common LISP:
1. всегда есть запущенный environment.
2. есть один буфер, в котором Вы пишете Вашу ф-цию.
3. дописали, нажали шорткат -> она ушла в environment
4. пишете (foo 1 2 3), жмете шорткат -> (foo 1 2 3) выполнилось и вы видите результат выполнения
5. не понравился результат? идете к пункту 2
Приблизительно это уже есть в Slime. Причем давно.

В случае с моим любимым Haskell это НЕ реализовано. Но могло бы быть еще удобнее, потому что язык _чистый_.
Схема была бы та же, но не надо было бы нажимать шорткаты вообще.
— импорты в редактируемом модуле и уже введенные определения это environment
— пока пишешь выражение, его тип и значение автоматически вычисляются и показываются в рядом или в status bar'е каком-то.

Но Вы очень любите REPL. Любите дальше.

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>В случае с Common LISP:
RD>1. всегда есть запущенный environment.
RD>2. есть один буфер, в котором Вы пишете Вашу ф-цию.
RD>3. дописали, нажали шорткат -> она ушла в environment
RD>4. пишете (foo 1 2 3), жмете шорткат -> (foo 1 2 3) выполнилось и вы видите результат выполнения
RD>5. не понравился результат? идете к пункту 2
RD>6. ?????
RD>7. PROFIT

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

MC>Лично я предпочитаю отредактировать файл, сохранить, а потом целиком загрузить его в интерпретатор. Т.е. все тот же подход с 2 буферами.

ОК, отредактировали, загрузили в интерпретатор, поэкспериметировали 5 секунд и поняли что пара ф-ций написана неправильно.
Что дальше?
Я вижу два варианта:
1. попробовать изменить эти фунции прямо в REPL и проверить. Это потребует вернуться назад к исходнику, вытащить тела ф-ций, загнать их в REPL и там менять. А потом назад засунуть исправленные версии.
2. изменить сразу же в исходнике и снова загрузить все в интерпретатор.

Есть ли третий способ?

Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>ОК, отредактировали, загрузили в интерпретатор, поэкспериметировали 5 секунд и поняли что пара ф-ций написана неправильно.
RD>Что дальше?
RD>Я вижу два варианта:
RD>1. попробовать изменить эти фунции прямо в REPL и проверить. Это потребует вернуться назад к исходнику, вытащить тела ф-ций, загнать их в REPL и там менять. А потом назад засунуть исправленные версии.
RD>2. изменить сразу же в исходнике и снова загрузить все в интерпретатор.
RD>Есть ли третий способ?

Я вторым пользуюсь.

Здравствуйте, volk, Вы писали:

V> Common Lisp + emacs + SLIME.
V>Вкратце: эта конфигурация для задач быстрого старта себя не оправдала нисколько.

Всё же, при всём богатстве выбора другой альтернативы нет. Поэтому лично я не вижу для новичка смысла пытаться использовать что-то другое. Хотя, есть CUSP. Этот более или менее.
Поэтому для целей именно старта и именно новичка уж если не завёлся Emacs+SLIME, то тогда окружение CLISP'а. И ничем другим извращаться смысла не вижу, хотя, кому как.

Здравствуйте, volk, Вы писали:


V>To be continued...

Большое спасибо. А что скажите насчет коммерческих решений (как и было освящено в статье, с точки зрения быстрого старта)? Allegro вроде имеет бесплатную версию. Я себе ставил, но дело не пошло, правда скорее по личным причинам.

Здравствуйте, Rtveliashvili Denys, Вы писали:

RD>Аналог GHCi в Хаскере или просто запуска python без агрументов в питоне? Мрак, это еще хуже, чем я думал.
RD>Может Вы С# код пишете в notepad? Я тоже когда-то так делал. Но не долго.

Отчего же такие неправильные выводы делаем? На шарпе вполне себе пишу в студии.

RD>В случае с Common LISP:
RD>1. всегда есть запущенный environment.
RD>2. есть один буфер, в котором Вы пишете Вашу ф-цию.
RD>3. дописали, нажали шорткат -> она ушла в environment
RD>4. пишете (foo 1 2 3), жмете шорткат -> (foo 1 2 3) выполнилось и вы видите результат выполнения
RD>5. не понравился результат? идете к пункту 2
RD>Приблизительно это уже есть в Slime. Причем давно.

Слушай, я тебе про это и рассказываю, я точно так же и делаю, может неправильно, но называю все это repl'ом Вот в slime и есть тот самый нелюбимый тобой repl. Правда в slime есть еще много чего вкусного кроме этого, но это уже другая история.

RD>Но Вы очень любите REPL. Любите дальше.

Я люблю удобство

yumi пишет:

> RD>Но Вы очень любите REPL. Любите дальше.

Слушайте, хватит уже. Ну сколько можно ?

Здравствуйте, saturas, Вы писали:

S>Большое спасибо. А что скажите насчет коммерческих решений (как и было освящено в статье, с точки зрения быстрого старта)? Allegro вроде имеет бесплатную версию. Я себе ставил, но дело не пошло, правда скорее по личным причинам.

Как пользователь Allegro скажу, я не пользуюсь IDE Allegro. Я пользуюсь в первую очередь их очень неплохим компилятором, библиотеками, ... Кроме IDE, ну как-то не пошло оно, видимо это скорее всего привычка, но честно сказать сама IDE, редактор форм и прочие штуки выглядят не очень красиво и не очень так скажем современно Особенно в сравнении с Visual Studio.

Здравствуйте, cl-user, Вы писали:

CU>В первую очередь — проблемы у автора с головой.