Состояние экосистемы Common Lisp на 2015 год

Что tkinter таскает с собой интерпретатор тикля это как бы не секрет, к чему все эти открытия?)

Подписываюсь под тем, что тебе monk ответил. Касабельно ORM (равно как и других обёрток), они представляют собой всего лишь узкое окошко в мир SQL, через которое не так-то и удобно в него смотреть. Моё мнение - почти никогда не нужны.

А если 90% того SQL — именно код на SQL со сложной логикой,

Производителен именно код на SQL. Хранимые процедуры. Именно они позволяют добиться ускорения некоторых действий в 100 или 1000 раз по сравнению со всяческими ORM.

Да не к чему. Хотел сагитировать человека в свою веру, а потом в свой проект. Уже почти поругались. Надо валить мне из этой темы, а то за сегодня ничего не сделал полезного :)

Жаль. Мне просто интересна точка зрения.

Я могу коротко повторить. Бросай читать с первого пункта, с которым не согласен.

Текст, разбитый на абзацы, читать легче, чем текст без абзацев. Раскрашенный код читать легче, чем не раскрашенный.

Почему? Потому что «глазу есть за что зацепиться». В tcl есть разные скобки, есть ключевое слово else. За него глаз и цепляется. В лиспе всё круглое, одинаковое, зацепиться не за что, читать труднее. Это может быть не осозноваемо, но это наверняка можно замерить. Я не замерял, мне и так это очевидно.

Дальше. В тексте есть предлоги. Предлоги короче других слов. Почему? Из-за частотности. С другой стороны, буквы плюс-минус километр, но равномерно распределены по встречаемости. Если взять лисп, то в нём скобки торчат - их слишком много. А остальных символов слишком мало. Значит, лисповый текст неправильно построен по частотам и его можно заархивировать с большей степенью сжатия. Иными словами, в нём больше воды и меньше содержания, и эту воду предтсавляют из себя скобки.

Далее, идиотские длинные названия для сущностей, типа multiple-value-bind, реально снижают популярность полезных возможностей, потому что человек подсознательно стремится излагать мысли более коротко, чтобы меньше печатать. И избегает длинных конструкций. Во всяком случае, ленивый человек, а программист должен быть ленив.

Далее, пробел, точка с запятой или скобка. Меньше всего усилий нужно для чтения пробела. Труднее прочитать одну точку с запятой. Скобка требует больше всего усилий. Глаз постоянно спотыкается, читая скобку за скобкой. Поэтому синтаксис tcl хорош - в нём полно пробелов и нет даже точек с запятой. Синтаксис питона тем же хорош.

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

{
let a 1
let b 2
a+b
}

(let ((a 1))
  (let ((b 2))
    (+ a b)))

(progn
  (let ((a 1))
    (something a))
  (something else))

(progn
  (let ((a 1))
    (something a)
    (something else)))

Пишу только потому, что ты попросил.

Поэтому синтаксис tcl хорош - в нём полно пробелов и нет даже точек с запятой.

Там есть самые разные скобки. Это тоже TCL:

set f [list {a b} {expr {sqrt($a*$a+$b*$b)}}]

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

Мне хватало комментариев, пустых строк и ключевых слов. Вот например:

(rfc2109:make-cookie
   :name name
   :value (escape-as-uri value)
   :comment comment
   :domain domain
   :max-age max-age
   :path (awhen path
           (escape-as-uri it))
   :secure secure)

Это значит, что отдельная лексическая область видимости в let не требует текстуального выделения. И так понятно, что переменная определена _вниз_ от места определения, не нужно ещё и _вправо_ сдвигать текст. Но лисперы это никогда не понимают, и я не рассчитываю и сейчас, что меня поймут.

Там так сделано намеренно. Чтобы было неудобно писать длинные функции. Потому что их потом неудобно читать на любом языке.

Кстати, почему тогда не Scheme?

(define (foo x)
  (cond
    [(number? x)
     (define s (+ x 1))
     (define (p a) (+ a 1))
     (p s)]
    [else (error 'foo "Should be number")]))

Вполне красиво, лишних отступов нет, лексическая область для define — текущий блок. Скобки разные — глазу есть за что уцепиться. И даже для Common Lisp есть бесскобочный синтаксис: http://sourceforge.net/p/readable/wiki/Common-lisp-tutorial/

В tcl есть разные скобки, есть ключевое слово else

В Tcl нет ключевых слов.

В лиспе всё круглое, одинаковое, зацепиться не за что, читать труднее.

Принципиальных проблем с восприятием S-expressions у человеческого мозга нет. Всё читается по отступам, ключевым словам... другими словами, читается как и всё на свете по знакомым формам. Касательно чтения, классическая проблема типового программиста - привычка к алголо-си-подобному синтаксису.

Ну, уж обсуждать я точно не подписывался. Ты хотел мнение - на :) Почему не Scheme, почему сделано так а не этак. Это уже уход в другие темы. Ты спросил, почему считаю неудобным - я ответил. Вообще сегодня слил я трудовой день, а надеялся кого-нибудь из вас мобилизовать в свою веру :) Лучшее утверждение своей веры - это написанный код :)

Это может быть не осозноваемо, но это наверняка можно замерить. Я не замерял, мне и так это очевидно.

Очевидно?! Я предлагаю тебе начать знакомится с особенностями восприятия информации человеком с вот этой простой книги Дэниела Канемана - http://www.ozon.ru/context/detail/id/24286114/?gclid=COXK7K-N7ccCFYTDcgodASEO... Если прочтёшь, ты искренне посмеёшься над своими, достаточно детскими рассуждениями о восприятии! Кстати, как научишься замерять, дай знать. Нобелевка тебе обеспечена.

Если взять лисп, то в нём скобки торчат - их слишком много.

Ну уж тебе-то должно быть известно, что скобки в Lisp никто не читает.

Принципиальных проблем с восприятием S-expressions у человеческого мозга нет.

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

Как доделаешь свои биндинги - звони во все колокола, пихай их на cliki и т.п. Может и сгодятся для чего-нибудь. В принципе, конечно, было бы полезно иметь образ дерева видгетов в лиспе и ассоциировать с tcl-ным деревом видгетов лисповые данные. Желательно, чтобы они ещё и умирали при дестрое окна. Думаю, это как-то можно сделать при помощи snit. Но в целом моё отношение к биндингам скептическое. tcl - это один из последних языков, для которых они могли бы понадобиться. С, Java - тут можно понять нужду.

Ну уж тебе-то должно быть известно, что скобки в Lisp никто не читает.

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

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

Ну уж тебе-то должно быть известно, что скобки в Lisp не just for fun! Они-то как раз нужны как инструмент, что бы воды да boilerplate-а было поменьше.

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

Действительно. Но ведь нужно быть совершенно упоротым лиспером, чтобы не знать, что пара «лишних» скобок в let, не just for lulz.

(let ((a 0)
      (b 0))
  (+ a b)

{
let a 1
let b 2
a+b
}

Моя цель была обратить тебя в свою веру

Я атеист. Без обид :)

А если тебе интереснее меня уличить, то уже можно радоваться - уличил.

Конкретно «уличать» и критиковать кого-то не самоцель. Предпочитаю критиковать и «уличать» различные мнения и гипотезы опираясь на аргументы и факты. Чем убедительнее аргументы, чем больше фактов, тем больше шансов у мнения быть принятым в расчёт. Вот и всё.

типа multiple-value-bind, реально снижают популярность полезных возможностей

Популярность среди Lisp-еров что-ли? :) Все знают что такое multiple values и все это используют.

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

Ты в блокноте что-ли CL код набиваешь? Если так, то конечно. Тут полный провал, ничего не возможно написать. А так вообще, auto completion есть.

чтобы меньше печатать

Круто конечно, но тут меру нужно знать. А то ведь мы все знаем, кто такой Золотце и что такое Symta :) Там всё кратко, аж до дрожи.

Вот собственно, тут мы и наблюдаем то, о чём я сразу говорил: доказывать безполезно :)

Мог бы получиться неплохой срач страниц на 50. Но это не нужно.

Вот собственно, тут мы и наблюдаем то, о чём я сразу говорил: доказывать безполезно :)

Да ты не обижайся, что как маленький. Лучше сразу говори, что не так-то. Аргументы приводятся. Давай контраргументы, коль считаешь, что правда на твоей стороне :)

Поэтому синтаксис tcl хорош - в нём полно пробелов и нет даже точек с запятой. Синтаксис питона тем же хорош.

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

Далее, идиотские длинные названия для сущностей, типа multiple-value-bind, реально снижают популярность полезных возможностей, потому что человек подсознательно стремится излагать мысли более коротко, чтобы меньше печатать. И избегает длинных конструкций. Во всяком случае, ленивый человек, а программист должен быть ленив.

А как насчёт названий классов и методов в самом популярном сегодня языке программирования, например: AbstractQueuedLongSynchronizer. Или же AccessibleAttributeSequence. Я уже промолчу про createDocumentFragment(), createProcessingInstruction() и т.п? :-) Длинные названия не мешают сегодня писать на этом языке больше всего, как на Коболе, в своё время :-)

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

Моя задача - чтобы кто-то мне помогал делать мою IDE. Сегодня я практически убил день на то, чтобы тебя подбить на это дело, поскольку ты работаешь в сходном направлении. Но наши с тобой правды слишком отличаются. Более того, начав с осмысленной темы о нужности/ненужности обвязок для tcl, мы скатились в совершенно пустую тему об удобстве/неудобстве синтаксиса лиспа. Я не обиделся, просто я вижу, что не удаётся тебя привлечь и пытаюсь урезать временнЫе издержки. Если бы я за сегодня написал полезный код, я бы гораздо больше приблизился к тому, чтобы кто-то стал мне помогать в моей работе.

По ходу дела, уже без всякой агитации, мне захотелось поделиться с тобой (да и со всеми) опытом, состоящим в том, что обёртки в виде s-выражений нужны довольно редко. Задача решается по-другому. Я практически сравнил подходы и убедился. А уж если это tcl, то вообще обёртки не нужны - небольшое упражнение, состоящее в том, чтобы выучить tcl, гораздо дешевле, чем делать обвязки. Дальнейшая работа на tcl по производительности труда сопоставима с работой на лиспе и явно быстрее, чем работа с tcl на лиспе через обвязки. Такой подход очень быстро окупается. В моём случае уже окупился - просто посмотри на календари разработки clcon и ABLE и на список фич. Ну или хотя бы на объём сорсов.

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

Тебе, может быть, интересно спорить, а я понимаю, что я не вечен. Я лучше код какой-нибудь напишу, чем 100 страниц пустых (или мудрых) комментов.

Касабельно ORM (равно как и других обёрток), они представляют собой всего лишь узкое окошко в мир SQL, через которое не так-то и удобно в него смотреть. Моё мнение - почти никогда не нужны.

Абсолютно правильно. Любая ORM - это никчёмное ярмо на шее несчастного одураченного «модной фишкой» программистишки, который вместо того, чтобы инвестировать в изучение SQL, чтобы потом спокойно писать запросы произвольной сложности в наглядном и строго формальном виде, инвестирует время сначала в изучение, потом в утомительное сопоставление сущностей БД с классами ORM, потому что так завещали бородатые воротилы ООП :-) Гыгы.

Вообще сегодня слил я трудовой день, а надеялся кого-нибудь из вас мобилизовать в свою веру :) Лучшее утверждение своей веры - это написанный код :)

Ты сильно ошибся и, походу, ошибаешься до сих пор. Уже давно просматривается такая особенность так называемых лисперов, как одиночество. Они все и всегда сидят по углам. Им трудно работать коллективно и сообща. Вернуться вот к тому же SBCL. Факт в том, что там много коммитов от разных людей. Но другой факт в том, что сие коммиты очень редко когда обсуждаются. Т.е. каждый делает то, что считает нужным. Очень опасная модель разработки - нет лидера, прям демократия :-) Это в корне отличается от, скажем, Postgres. Там каждый чих сначала обсуждается, выслушиваются мнения, критика, рождаются новые версии патчей и только потом патч добавляется в «очередь коммитов». Как результат - коллективная работа очень качественного продукта. А лисперы сидят в своих углах в оборонительной позиции, кто-то со своими проектишками, кто-то «ВНОСИТ ВКЛАД В СООБЩЕСТВО», но организация у них почти нулевая. :-) Так что ты, скорее всего, никого из лисперов не заинтересуешь. Они заняты S-выражениями :-)

Моя задача - чтобы кто-то мне помогал делать мою IDE.

Бюджет нужен. Или перспективы радужные, хотя бы :-) В мире, где за всё надо платить, за всё надо платить. А платить без отдачи как-то глупо. Вот если бы ты мог свою IDE потом продавать, то для тебя это был бы стимул. Но нехорошие редиски (но хорошие бизмесмены), внедрили в обиход бесплатное ПО. И десятки тысяч, которые на эту пропаганду повелись, штампуют оное в надежде завоевать симпатию, привлечь внимание, чтобы, если только повезёт, занять свой кусочек под солнцем. Нормальная и простая практика продажи изделия, которое ты сделал, выпилена на рынке ПО. А ведь хорошие программы, по сути, должны быть коммерческими, потому что это справедливо :-)

Пиздец, он снова тут. Иди отсюда, наркоман.

Ну вот, второй раз отвечаю сегодня анонимусу. Я отправлял свои патчи в asdf и в slime. Ни один не принят, но было вполне живое и содержательное обсуждение из нескольких человек, проверка на соответствие политикам, выдвижение альтернатив, критика, приняли в один из форков slime. Так что не всё так уж безнадёжно.

Патч в slime приняли бы, но я не довёл дело до конца.

Я отправлял свои патчи в asdf и в slime. Ни один не принят, но было вполне живое и содержательное обсуждение из нескольких человек

Ты - человек со стороны. Тебе было деваться некуда, кроме как отправить патчи в список рассылки. Я же говорю о тех, кто имеет доступ к исходникам. Подпишись на список рассылки, кажется, sbcl-devel и посмотри как часто там обсуждаются те или иные добавления. И сравни с количеством коммитов. Сложится впечатление, будто там все сами по себе :-)

утомительное сопоставление сущностей БД с классами ORM, потому что так завещали бородатые воротилы ООП

Что-то ты всё с ног на голову перевернул. Это без ORM надо вручную сопоставлять классы в программе результатам запроса из БД. И наоборот, правильно сохранять состояние хранимых (persistent) данных в таблицах БД.

А если есть нормальный ORM, то про БД вообще не надо думать. При записи в объект данные запишутся куда-то в БД. И ORM даёт возможность получить список объектов из БД по заданному условию. Причём, если это нормальный ORM, то условие может выглядеть и как (and (> f1 0) (< (factorial f1) 1000)). В смысле, не ограничиваясь куцыми возможностями SQL.

шо, опять ORM vs. SQL? Да ну в пень. Хуже чем си против пролога, чесслово

ORM vs. SQL? Да ну в пень.

Так уже обсудили SBCL vs Lispworks, CL vs Racket, Tcl vs Lisp. Почему бы и не ORM vs SQL?

Хуже чем си против пролога

Можем и «си против пролога», почему бы и нет?

Почему бы и не ORM vs SQL?

А там есть что обсуждать? Или каждой задаче - свой инструмент? Для быстрого прототипирования, наверное, ОРМ будет полегче (в смысле - разработка быстрее). Для получения максимальной отдачи от sql-сервера без sql не обойтись. Всё, что «между» этими пунктами - на усмотрение и/или в зависимости от прочих факторов.

Что-то ты всё с ног на голову перевернул. Это без ORM надо вручную сопоставлять классы в программе результатам запроса из БД. И наоборот, правильно сохранять состояние хранимых (persistent) данных в таблицах БД.

Для какой-такой волшебной ORM не нужно в каком-нибудь XML приводить описание сущностей БД? Я могу допустить, что ORM может иметь реверсивный инжениринг и по метаданным БД сгенерировать начальное описание модели сущностей. Но не все физические таблицы БД являются логическими сущностями проекта. Например, физические таблицы, обеспечивающие связь «многие-ко-многим» сущностями не являются по определению. Это нужно исправлять руками по-любому. Кроме того, структура данных в базе тоже меняется. И вот эти изменения всё равно придётся учитывать вручную в модели описания для ORM. Т.е. необходимость синхронизации метаданных ORM с метаданными БД - это всегда ненужные и стоящие того хлопоты. То, что, например, на стороне HTTP-сервера будет прослойка из классов, которые поставлены в соответствие с классами БД, ничего кроме самообмана вроде «зато я соблюдаю каноны ООП» не даст. Дальше больше. По-мимо таблиц в хорошем проекте БД ещё и существуют функции. Если функции так или иначе связаны с сущностями (т.е. являются методами, если угодно), то создаётся соблазн создавать обёртки и для этих функций как методы классов ORM. Сия утомительная и подверженная ошибкам работа - самый что ни на есть мартышкин труд. :-)

А если есть нормальный ORM, то про БД вообще не надо думать.

Это всё сказочки про белого бычка. Про БД не надо думать, если её нет. :-)

При записи в объект данные запишутся куда-то в БД.

Как говорится омиреганцами, automagically? :-)

И ORM даёт возможность получить список объектов из БД по заданному условию.

И для того, чтобы научиться этим пользоваться в данной конкретной ORM, надо потратить столько же времени, сколько нужно потратить на изучение стандартного SELECT SQL. :-)

Причём, если это нормальный ORM, то условие может выглядеть и как (and (> f1 0) (< (factorial f1) 1000)).

Ты что, правда SQL не знаешь и того, что в БД можно функции определять? :-)

SELECT * FROM foo WHERE f1 > 0 and factorial(f1) < 1000

В смысле, не ограничиваясь куцыми возможностями SQL.

Куцыми можно назвать возможности любой ORM по сравнению с развитой СУБД, вроде Postgres. Никакая ORM не обойдёт по возможностям и по производительности/экономии трафика SQL + хранимые процедуры СУБД. :-)

Для какой-такой волшебной ORM не нужно в каком-нибудь XML приводить описание сущностей БД?

Например:

(defstar-shield:defptype even-string ()
  `(and string (satisfies string-has-even-length-p)))

(cl-perec:defpclass* tps-report ()
  ((report-title :type boring-string)
   (report-text  :type even-string)
   (report-path  :type pathname)))

Если связи надо описать, так

(cl-perec:defassociation*
  ((:class corporation
    :slot employees
    :type (cl-perec:set generic-guy))
   (:class generic-guy
    :slot employer
    :type corporation)))

Зачем сущности БД?

automagically

Да.

в БД можно функции определять

Ну ладно, пусть будет (select (f file) (where (and (> (size f) 1000000) (file-exist-p (filename f)))). Или наличие файла на клиентской машине тоже в хранимую процедуру запихнешь?

Никакая ORM не обойдёт по возможностям и по производительности/экономии трафика SQL + хранимые процедуры СУБД

Я как-то видел как фанаты Oracle на хранимых процедурах решение дифуров писали. Не сказал бы, что было сильно быстро.

В реальном мире почти всегда быстрее вытащить рабочий набор из БД и считать на клиенте.

изучение стандартного SELECT SQL

В стандартном SELECT SQL очень не хватает доступа к полям полей и переменных. Типа

WITH reg = CASE
             WHEN GTD = "" THEN "Russia"
             ELSE employee.org.region
           END
SELECT reg, 
       CASE WHEN reg IN (&Selected) THEN 1 
            ELSE 2 END AS status, 
       sum(value) 
FROM sales GROUP BY reg, status

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

Нет. Вот автоматика:

(def persistent-class* student ()
  ())
   
(def persistent-class* course ()
  ())

(def persistent-association*
  ((:class student :slot courses :type (set course))
   (:class course :slot students :type (set student))))

А ассемблер не уступает любому ЯВУ. Важные не только теоретические выразительные возможности, но и удобство использования. Если что-то сделать можно, но с такой-то матерью - то это значит, что на самом деле (на практике) нельзя.

Может же быть тому какая-то объективная причина кроме AI Winter, маркетинговых раскладов

А этого не достаточно?

Да не хочется. Я эту задачу для себя решил, ссылку на код дал. Добиться распространения моего решения не удалось. Проблем с другими лисперами поимел, когда нанял человека, не готового освоить это решение.

Тебе же уже сказали- в нормальных лиспах есть internal definitions.

Если взять лисп, то в нём скобки торчат - их слишком много. А остальных символов слишком мало.

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

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

аещеможнописатьбеспробеловизнаковприпинаниятекстостаетсявполнепонятенноприэтомоказываетсяболеесжатвнембезпробеловменьшеводыибольшесодержания

н, странное дело, при этом читабельность падает как же так?

Далее, идиотские длинные названия для сущностей, типа multiple-value-bind, реально снижают популярность полезных возможностей, потому что человек подсознательно стремится излагать мысли более коротко, чтобы меньше печатать.

Если под «человеком» подразумевать васю-первокурсника - то, наверное. Тот же, кто имеет хотя бы минимальный опыт программирования, старается сокращений в коде не допускать, как известно.

Синтаксис питона тем же хорош.

Но синтаксис питона в прямую скопирован с лиспа, лол. Он ему эквивалентен, причем совершенно строго. Ты чушь несешь полную.

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

Здесь проблема не в лисперах, а в тебе, лол. Создавать новую область видимости нельзя, как ты предлагаешь, это ломает экспандер нахрен, не говоря уже о том, что по коду с макросами просто _нельзя предсказать_ где и какие области видимости вводятся, не раскрыв сначала все макросы (и, с-но, нельзя понять код, не раскрыв макросы). Твое предложение приводит к целому ряду фундаментальных проблем и _резко_ снижает читабельность когда.

Я так понимаю, что den73 хочет просто сказать, что, дескать, «есть такие-то переменные с такими-то значениями, пожалуйста, используй их по всей функции». Такое можно сказать без let, для этого есть &aux. Но я обычно таки let пишу, мне больше нравится.

Зачем сущности БД?

Хорошо, я тебя услышал. Т.е. предлагается описывать модель данных на Lisp. Возникает первый резонный вопрос: будет ли описываемая на Lisp модель автоматически синхронизироваться с физическим представлением в СУБД? Если ответ на этот вопрос «да», то т.к. задача далеко не тривиальная, как это может показаться, возникает второй резонный вопрос: зачем тогда нужно использовать это с реляционной СУБД, где языком описания модели данных служит SQL, если вместо этих всяких cl-perec гораздо более естественным и красивым решением было бы создание СУБД на Lisp и для Lisp, типа AllegroCache? Если ответ на первый вопрос «нет», то никакой реальной выгоды от твоего «перца» нет. Это просто дополнительный мартышкин труд и зарабатывание геморроя при обеспечении синхронизации описания модели на Lisp и физическим представлением. И ещё, в том же Postgres обычно очень много специфических возможностей, таких как триггеры и система правил, которые ничем не заменишь для обеспечения целостности данных. А ещё есть виды, безопасность на уровне строк (в 9.5) и много-много всего. Всё это программируется с помощью SQL или PL/pgSQL. Тем, кому это надо, всё равно будут иметь много дела с SQL. И заморачиваться с описанием модели данных на Lisp - это лишь дополнительные хлопоты без особой выгоды. :-)

Ну ладно, пусть будет (select (f file) (where (and (> (size f) 1000000) (file-exist-p (filename f)))). Или наличие файла на клиентской машине тоже в хранимую процедуру запихнешь?

Что-то я не понял к какой машине ты пытаешь сделать запрос? Если к серверу Postgres, то какая-нибудь file_exists(f) будет смотреть на файл f, расположенный на примонтированной ФС к серверу Postgres. Но это какой-то надуманный пример. В Postgres принято хранить большие данные в bytea, поэтому запрос твой будет выглядеть как-нибудь так:

select * from image where length(data) > 1000000

Я как-то видел как фанаты Oracle на хранимых процедурах решение дифуров писали. Не сказал бы, что было сильно быстро.

Смотря на каком языке писать. В Postgres легко можно писать их на C. Думаю, ты был бы удовлетворён скоростью C :-)

В реальном мире почти всегда быстрее вытащить рабочий набор из БД и считать на клиенте.

В некоторых случаях да. Так, вот такой код

select sum(i) from generate_series(1, 1000000000);

(loop for i fixnum from 1 to 1000000000 sum i)

будет ли описываемая на Lisp модель автоматически синхронизироваться с физическим представлением в СУБД? Если ответ на этот вопрос «да», то т.к. задача далеко не тривиальная, как это может показаться

perec синхронизирует. Если меняешь класс, то меняется таблица. Через ALTER TABLE.

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

pereс даже что-то из этого вроде использует. Но опять же, на основании модели из лиспа.

к какой машине ты пытаешь сделать запрос

«Выбрать из БД все описания файлов, если эти файлы существуют на текущей машине». ORM в этом случае проверку на размер завернёт в SQL, а проверку на существование файла применит к получаемым данным.

Но это какой-то надуманный пример.

Пример из жизни: выбрать остатки по номенклатуре в определённой группе.

(defun (in-group nom grp)
  (let ((p (parent nom)))
    (when p
      (or (eql p grp)
          (in-group p grp)))))

(select ((goods-of rests) (sum (rest-of rests)))
        (from rests)
        (where (in-group (goods-of rests) my-group)  
        (group-by (goods-of rests)))

Будешь на PL/SQL рекурсивную функцию писать? И для получения поля SELECT из базы делать?

Но это какой-то надуманный пример. В Postgres принято хранить большие данные в bytes

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