На практике по конструированию в институте писали расширения для 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