Интересно кто для чего использует Lisp

хоби. Узнать что-то новое

Изучал. Хотел найти применение, не нашёл (как и с Prolog, кстати). Понимаю важность декларативного программирования, но, думаю, она начнёт, скорее, появляться, в императивных языках.

Немного продвигается идея GNU насчет открых исходников
Для маленьких задач очень удобно все программировать на Лиспе (а он по сути явный интерпретатор то бишь GNU)
Может быть этот язык  будет все все более популярным

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

А REPL чрезвычайно удобен не только для маленьких задач.

Думаю, будущее за многопарадигменными языками. В императивные языки уже стали вводит функциональные средства (Python, C# 3.0, Fortran). Также имеются языки и с другой стороны: Common Lisp, Visual Prolog (VPI), которые являются многопарадишменными. Вопрос в том, с какой стороны лучше двигаться к этому. Думаю, со сороны императивных это будет легче и логичнее, как когда-то был переход asm -> FORTRAN. Это следующая серьёзная стадия эволюции импертивных языков: повышается надёжость кода, уменьшается его размер, повышается интеллектуальность компиляторов, всё больше ошибок будет проверяться на этапе компиляции, программирование приобретает декларативные черты. Что же касается CL, то, возможно, просто на его нише рядом с ним стоят другие, более "привлекательные" языки.

Мало знаком с Lispom, но видел пару исходников на нем. Сложилось впечатление, что поддерживать и сопровождать калькулятор, написанный на лиспе, сложнее, чем веб-сервер, написанный на асемблере. Думаю, в этом и кроется причина непопулярности лиспа для повседнеынх прикладных задач. Возьмите любой проект на Java, .NET, C++ - если сделано как положено, перед тобой будет четко структурированный код. На втором месте стоит, конечно же, отсутствие приличной инфраструктуры для лиспа - если сравнить с перечисленными технологиями и языками, число библиотек и пр. готовых решений ничтожно мало, а сущетсующих портов не хватает.
Видимо, применение Лиспа и в дальнейшем будет ограничено специфическими областями? Кстати, кто-нибудь не расскажет об особенностях применения Лиспа при решении задач ИИ?

Совершенно неверное впечатление. Сложность восприятия в значительно большой мере определяется уровнем абстракций, которыми оперирует код, нежели синтаксисом, будь то S-выражения или привычный алголоподобный синтаксис.
Думаю, стоит почитать «On Lisp» Пола Грэма, хотя бы первую главу.

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

Я написал комментарий к конкретной фразе, которую процитировал. Если действительно встанет такая необходимость, поддержка хорошо спроектированного ПО на Лиспе вряд ли будет сложнее, чем мегатонны индусского кода на C++/Java/whatever. Мозг адаптируется к синтаксису быстро.

Впрочем, написал и вспомнил один эпизод: когда тот же Пол Грэм ушёл из Yahoo, они вынуждены были в значительной мере переписать созданный им на Лиспе движок «Yahoo! Store» на, если не ошибаюсь, PHP. Но конкретные причины этого решения могут быть не столь очевидны.

Void, а разве Lisp имеет железную защиту от индусов? Даже если особенности функционального подхода, который реализован в Lips'e, и позволяют избавиться от распространенных ошибок, присущих императивному стилю, все равно универсальной защиты от дурака нет и быть не может. К тому же есть очень большие сомнения по поводу пригодности использования функционалки в болльших проектах. Вопрос еще спорный, что будет лучше выглядеть и легче поддерживаться - код на Lisp, пусть и свободный от слайд-эффектов, или грамотно спроектированный проект на C++/Java/.NET. Системные архитекторы ведь не зря свой хлеб жуют.

Добавлено @ 16:39 
Void, нет ли у тебя информации, насколько язык реализации влияет на эффективность проектирования ИИ? В частности, желательно бы получить сравнение какого-нибудь универсального императивного языка -cpp forexample- и того же Lisp-a?

Аллергия на скобки обычно проходит через 3 дня, перестаешь замечать.

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

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

Ну и вдогонку. Не стоит забывать, что стандарт ANSI Common Lisp не поддерживает инкапсуляцию - а как быть без нее, и на кой без нее нужен полиморфизм? Я даже вот так скажу: как без инкапсуляции можно эффективно реализовать объектный полиморфизм? Быть может там есть какие-то языковые особенности, которые позволяют это обойти (повторюсь, я практически не знаком с языком), но сам факт настораживает.

Добавлено @ 16:52 


Если, скажем, проект уровня предприятия?

Промышленно применяемый Lisp ( Common Lisp в основном ) не является функциональным языком и даже не
пропагандирует функциональный стиль, скорее наоборот, удобство работы с динамическими переменными
и успех CLOS делают его использование более императивным чем всех прочих языков.

Единственный из известных мне языков, который успешно и  оправданно на практике следует функциональному 
стилю - Erlang.

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



Не понял различия. Какая разница какой статус присвоен проекту?
Оперирующие "уровнями" код не читают, а читающим - наплевать на "уровень".

Это сообщение отредактировал(а) svg - 22.10.2006, 17:23

На практике по конструированию в институте писали расширения для AutoCAD на модификации LISP'a - AutoLISP'е аж с третьего курса и до  диплома. Некоторые даже защищались на прикладных программах.



Вовсе нет.  По сложности языка реализация сродни школьному BASIC. Мне так показалось. Во всяком случае, я его воспринял лучше, чем Фортран. Что до прикладных программ - то на языке выполняли коммерческий проект, ориентированный на инженеров, "туго" знающих конструкторское дело и требовавших быстродоступный инструмент для автоматизации разработки типовых узлов. Интерфейс получился интуитивно понятный, насыщенный всякими всплывающими окошками, менюшками, кнопочками, RADIO_BUTTON и т.д., а главное, он формируется легко.



А мне понравилось. Зато научился ставить скобки сразу парой. И теперь при компиляции приложений на высокоуровневых языках ошибки ')' expected не получаю.;)

Сейчас LISP в силу специфичности не использую.

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



Ну это просто пример большого проекта. Я имел ввиду просто большой проект. Многие говорят, что функционалка под них плохо подходит.



Интерфейс уже давно перестал быть проблемой. Все мейнстримовые платформы предоставляют прекрасные средства для построения интерфейса. А то, что ЛИСП очень специфичен - это верно подмечено. Мне кажется, если тянет на экзотику, имеет смысл обратить внимание на многопарадигменные языки - OCaml, F#, Nemerle (императивка+ООП+функционалка).

В CLOS методы являются объектами соответсвующей generic function, а не принадлежат какому-либо классу,
специализируются на типе или значении аргументов.

Смоделировать классы в стиле C++/Java в принципе не представляет труда, используя MOP и/или макросы,
но случаев, когда у кого нибудь возникала по ним тоска или необходимость я пока не встречал.




Опять же, Common Lisp не функциональный, а универсальный язык. Проект при его использовании может внезапно
стать из большого довольно маленьким, например у меня в CRUD-приложении около 80-ти классов, отображающих
модель базы данных и на каждый из них по три CRUD-формы (обычная MVC-модель). Весь код занимает около 50K,
так как и классы модели и формы по ним в основном генерируются макросами.

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



Всегда был и будет. Особенно сейчас, когда приложения становятся все более конкурентными и GUI является 
результатом взаимодействия десятков параллельных процессов. 
GUI легче всего программируется в объектном стиле, взаимодействие - в функциональном, а парадигмы/языка,
удобного для обоих случаев я пока не встречал.

а возможно посмотреть твой код?

Секретного ничего нет, но для стороннего использования я код не готовил, соотвественно есть только голые исходники.

иллюстративно, все выглядит так:


что генерирует следующее определение класса для CLSQL и метод для установки начальных значений слотов из словаря PostgreSQL:



Данные макросы генерируют формы просмотра, редактирования и поиска по сгенерированному выше классу:


Конечный результат выглядит так:


так

и так:


Это сообщение отредактировал(а) svg - 26.10.2006, 13:50

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

кстати, а использует ли кто лисп для web-а, какой web-сервер, что насчет шаблонов, mvc, как лисп внедрять в html, используете ли какой фреймворк?

Это сообщение отредактировал(а) farm - 26.10.2006, 17:18