Поступил вопрос в связи с открытой нами вакансией по Common Lisp:
Зачем вам функциональные языки? ... Типовая компания, ... . Знание торговли, склада, бухгалтерии. Внезапно, ... Lisp.

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

Common Lisp - это "обычный", императивный язык, хотя про это не все знают.

Как используем? Для скриптов и для сервера приложений.
Почему используем? Два ключевых преимущества:

1. Разработка программы происходит без остановки программы.
Можно, не выходя из приложения, добавить и удалить поля класса или поменять число параметров функции.
Уже существующие в памяти объекты при переопределении класса приводятся в соответствие с
новым определением, как при ALTER TABLE . Стек тоже не ломается. При возникновении исключения, в
отладчике можно направить исполнение "в другое русло" на любом уровне стека с помощью команд "перезапустить
кадр стека" и "вернуть нужное значение из кадра стека". Поэтому, регулярно бывает так: "падаем" на какой-то проверке в отладчик, исправляем ошибку и продолжаем выполнение дальше. Особенно полезно для долго выполняющихся скриптов.

Я немного интересовался аналогами в других языках и пришёл к выводу, что такого больше нигде нет. Если я неправ - киньте в меня тапком, я его внимательно обнюхаю. Особенно интересно будет услышать мнения пользователей J2EE и Visual Basic.

2. Расширяемый компилятор. Можно создавать новые конструкции языка, при "компиляции" которых
компилятор может делать всё, что угодно: читать из базы данных, интернета, создавать другие файлы, использовать информацию о ранее определённых классах и функциях.

С помощью этого технологично реализуются ORM, Embedded SQL, шаблоны, RAII, pattern matching, юнит-тесты.

Других чудес вроде нет. Перечислю просто хорошее: сборка мусора, компиляция в нативный код, полноценные треды, статическая и динамическая типизация, определение методов над встроенными типами, декораторы, комплишн, рефлексия, идентификаторы на Русском языке, слабые ссылки, лямбды, удобная визуализация в отладчике, кроссплатформенный ГУЙ (в лиспворкс).

См. также http://ecovillage.narod.ru/lisp/lisp-tutorial.htm

ГхостикНасколько я понимаю, макросы в лиспе - половина мощи языка. Вопрос - насколько они легко читаются?
Нормально читаются. Хотя чем мощнее ружье, тем больше будет дырка в голове, если выстрелить в себя.

Какие задачи вы решаете, что вам нужно делать на бою ALTER CLASS?
Не то, что "нужно" - полезно. Для почти любых задач полезно. Я вроде расписал довольно подробно, какие выгоды.

Но если это непонятно, давайте попробуем по аналогии. Представьте себе, что у меня и у вас есть какой-то SQL сервер и система торговли книжками. Но я не знаю о конструкции ALTER TABLE и не пользуюсь ей. Убедите меня в полезности ALTER TABLE.

Один пример новой конструкции языка, используемой у нас:
def-fb-patch. Её аргументы - название, комментарий и тело - скрипт на лиспе, который осуществляет шаг эволюции базы, например, делает alter table. Все такие патчи хранятся в одном файле. Благодаря тому, что это макрос, мы можем знать, какие патчи применены к данной базе, какие нет, когда и кем они применены.

Arm79, давайте последовательно. Тема ALTER TABLE не раскрыта. У нас тут профильный форум, я вижу вы с SQL работаете. Вы что, всерьёз считаете, что ALTER TABLE не нужен?

Arm79, ну вот, например, меняется закон. Например, добавили в книжку поле "возрастные ограничения". Его надо вывести в прайс-листе. Наши действия?

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

В случае какого-нибудь скрипта перекачки данных из одной базы в другую, если скрипт идёт час, а ошибку исправить 1 минута, то мы экономим полчаса, по сравнению с другими скриптовыми языками. У нас каждую ночь идёт скрипт длительностью около двух часов. Он сложный и иногда в нём возникают ошибки из-за кривых входных данных или сбоев оборудования. А утром база должна быть предоставлена пользователям. Трудно сосчитать, сколько часов ночной работы сэкономлено благодаря отладчику лиспа.

что не допускает рестарта сервера приложений в течении условно минуты?
Условно минуты или точно минуты? У вас есть сервер приложений? Вы его отлаживаете? Сколько времени у вас занимает поменять одну строчку в приложении и перезапустить сервер?

Arm79, ну если у нас аутсорс-фриланс, то тогда лисп точно не нужен.

MasterZiv, Delphi - по ряду причин.

С библиотеками у Дельфи ситуация в чём-то лучше, чем у CL. Поэтому
стараемся сочетать сильные стороны.

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

Arm79, вы уж извините за вопрос. Вы мне много вопросов задали. Какие у вас задачи?

и ещё я спросил "Сколько времени у вас занимает поменять одну строчку в приложении и перезапустить сервер? ", а вы мне ответили, сколько времени сервера приложений рестартуют. Это ответ не совсем на тот вопрос.

wadmanbuddenArm79, ну вот, например, меняется закон. Например, добавили в книжку поле "возрастные ограничения". Его надо вывести в прайс-листе. Наши действия?
Забавный подход... Такие вещи (атрибуты) не делаются полями таблиц, а делаются в виде справочников (иногда плавающих).
У меня, к примеру, в ПО можно прикрутить к любому объекту любой параметр и установить/получить его значение с помощью процедур. И это делается без изменения ПО и перезапуска сервера .
Я рад, что у вас такое славное "ПО", только не совсем понятно, что вы под этим понимаете. А что такое "процедура"? Она находится внутри "ПО" или снаружи?

Arm79, вот, SQL. Хорошо. Вы alter table делаете или нет?

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

wadman, на вопрос вы, однако, не ответили. Являются ли процедура частью ПО?

Само то, что в FB можно написать хранимую процедуру без перезапуска сервера, как вы говорите - это проявление родства между SQL серверами и лиспом. alter table = defclass, alter procedure = defun. Потому я в начале темы и привёл аналогию между defclass и alter table (хотя это скорее будет create or alter table). А можно ли сделать alter procedure в программе на C# или Delphi? Вообще говоря, нет.

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

Ну и PSQL - язык, конечно, убогий до слёз. Длина идентификатора недостаточная, пространств имён нет, структур нет. Ничего нет.

Arm79, ну так вы структуру таблиц меняете?

Arm79, а SSDТ внутри себя разве не alter table вызывает, когда вы правите описание таблицы?

Ну вот, наконец-то началось настоящее рубилово. Извините, мне надо поработать. Чуть попозже отвечу

Arm79, вы хотите знать куда я веду или для чего я использую лисп?
Что структура БД может меняться? Я с вами не спорю.

Мне сложно вас понять. Как не спорите, а это что вы раньше писали?
Чисто теоретически оно вам и не нужно ничего про неё знать, так как нет задач, требующих изменение БД на бою.

Что значит нет задач? Мы уже пришли к тому, что не только я, но и вы сначала меняете базу отладочную и потом накатываете изменения на промышленную. Значит, промышленная БД тоже меняется. И меняется она, я надеюсь, вы признаете, с помощью alter table, хотя ваш инструмент позволяет вам об этом не задумываться. Согласны или нет?

wadman, я не считаю свою архитектуру единственно правильной, но она одна из правильных. У нас реализована более-менее обычная трёхзвенка, правда, без ORM и на экзотическом языке сервера приложений.

Вы же в своём проекте фактически реализовали вторую реляционную структуру поверх уже существующей реляционной структуры СУБД. Я такое тоже делал, когда это было нужно (для ввода опросных листов переменной структуры и для ввода данных экспериментов переменной структуры). Такое решение имеет свои плюсы и минусы и у него есть своя область применения.

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

Нелояльный, я опробовал на практике достаточно много разных подходовв. Моя прошлая система на MS SQL (таблиц около 100, жила и развивалась лет 8 до прекращения бизнеса) была именно такой: вся бизнес-логика на сервере. Я был противником трёхзвенки и кричал на весь мир "вот как надо программировать, никаких трёхзвенок, sql рулит". Я и сейчас высоко ценю SQL - гениальная вещь.

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

Представьте себе такой мысленный эксперимент. Есть у вас ваш Firebird, но когда на сервере FB происходит Exception, появляется окошко "just in time debugging", можно запустить IBE и посмотреть место, где исключение возникло, глянуть переменные, вычислить что-то. Согласитесь, вот так надо бы работать в XXI веке. В FB (во всяком случае по состоянию на 2.5) такого нет, в MS SQL 2000, с которым я последним работал, этого не было. Думаю, и сейчас ещё такого там нет. Хотя если кто положит такую инфу в тапок и кинет в меня - начну копить на MS SQL :)

Вот ради такого удобства мы и перешли на трёхзвенку и теперь такое удобство у нас это есть.

Arm79, ну так и торговля бывает разная. Бывают клиенты со своими требованиями по оформлению документов, бывают хитрые управленческие отчёты, бывает просто очень большой объём данных, при котором производительность 1С не удовлетворяет. Бывают системы премирования менеджеров. Бывают филиалы. Бывает закачка документов из других систем. Бывают системы ранжирования товара. Всё это уникально для каждой организации и никак не покрывается стандартными конфигурациями 1С. И есть меняющееся законодательство, может быть, вы с этим не сталкивались. Если это 1С, то есть какая-то поддержка от вендора, а если это самописная система, то нужно успевать тянуть весь воз уже написанного кода за сменой законов. Мне казалось, это очевидно, поэтому я особо и не отвечал на это :)

По Дельфи - да справилось бы и Дельфи. Вопрос в объёме кода и сложности самого приложения. Чем сложнее приложение, тем больше преимущества лиспа за счёт возможности переопределять функцию на лету. Эти преимущества сказываются в уменьшении времени компиляции и в уменьшении времени на воссоздание ситуации, являющейся предметом изучения. Если ваши приложения компилируются за одну-две секунды, то они, видимо, довольно простые.

По сравнению с Дельфи - лисп надёжнее, т.к. он по работе с объектами больше похож на Java/C#, в нём сложнее промазать мимо памяти, хотя тоже можно. Намного сложнее добиться утечки памяти, или там Access Violation-ов. Соответственно, меньше возни с деструкторами. Это ведь само по себе, наверное, многих заставило перейти с Дельфи на C#. Настраиваемый отладчик. Например, можно сделать, чтобы в одном треде экспешн вызывал отладчик, а в другом возвращал экспешн пользователю, всё это можно программировать, а не мышью накликивать, как в Delphi. Ну и я не представляю себе какой-нибудь Delphi 2007, неделями висящий на промышленном сервере приложений. Он рухнет довольно быстро или всю память съест. А IDE лиспа у нас реально неделями крутится, т.е. все сорсы приложений и отладчик промышленной базы у нас всегда под рукой, если что.

Что ещё? Ну, допустим, хеш-таблицы по любым объектам элементарно строятся. Очень удобна работа с древовидными структурами. Я на Дельфи уже 13-й год потихоньку развиваю библиотеку работы с деревьями, но она до сих пор уступает тому, что в лиспе есть "из коробки".

wadmanизменение структуры бд может принести кучу сюрпризов
А мы умеем с этим справляться, потому что у нас за счёт макросов, которыми мы расширили PSQL, наборы параметров нужных нам хранимых процедур растут вместе со структурой таблицы. Система макросов для PSQL написана на лиспе. Клиентское приложение тоже в большой степени генерируется автоматически из структуры базы - генератор написан на лиспе. Оно заточено так, что редко возникают сообщения типа "field not found" или как там оно - не помню даже его текст, так давно не видел. Бывают и у нас сюрпризы с базой, они неизбежны по природе вещей, но крайне редко.

mayton, мы, в общем-то, готовы делиться нажитым, нам это выгодно. Хотя тут есть проблемы - не всё можно выложить в open source из-за NDA, многое нужно приводить в божеский вид, многое неудобно и т.п. Я говорю "мы", но 90% работы сделал я один, многое доведено до минимально рабочего состояния - мне же платят за решение прикладных задач, а не за развитие платформы. Если будет какой-то интерес, адрес указан в вакансии.