Возврат значения из замыкания

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

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

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

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

Потому что, ВНЕЗАПНО семантика программы зависит от семантики отдельных ее частей.

Идиот. Мы перенесли код из одной функции в другую. Как от этого изменится семантика программы в целом?!?

Нет, не можем, это алгоритмически неразрешимая задача.

Идиот. Возможных эффективных оптимизаций не так много.

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

А ты и в динамике этого не предскажешь. Поэтому в любом случае руководствуемся эвристиками.

Ты сколько суперкомпиляторов знаешь, ебанько, чтобы из них еще выбирать «вменяемые» и «невменяемые»?

А сколько эффективных трассирующих жытов ты знаешь? Только не надо про луа вякать, пруфов так никто и не показал.

Восторженные визги какого-то неведомого хмыря в мейллисте за пруф не считаются. Или конкретные бенчмарки, или вы все (включая того хмыря) - лживые скоты.

А это утверждение ты каким пальцем и из какой жопы выковырял?

И с какого перепугу семантика изменится, если код из одной функции будет перенесен в другую, если более нигде ни одна из них не используется?

Кто тебе сказал, что не используется?

А если и используется, то мы всегда можем их сдублировать.

Ну так покажи компилятор, который сдублирует, какие проблемы?

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

2^10^10? генерируй.

это покроет все возможные случаи.

А как ты будешь определять какой из специализированных инстансов применять вот в этом конкретном случае? Насуешь кучу проверок? Охуенная оптимизация, чо. Это говно в результате будет работать медленнее, чем оптимизированный код, лол.

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

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

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

Нет, это не выводится статически.

Эффективных специализаций всегда немного. Но найти их непросто, вычислительно дорого.

В рантайме - много. В компайлтайме - мало да. Но найти их просто и вычислительно очень быстро. почти мгновенно. Одна из самых простых оптимизаций ведь.

Идиот. На этом уровне любой язык будет не сложнее чем LLVM IR.

Ты ебанашка, при чем тут уровень? Дело в рантайме, под которым крутится язык, в его семантике. И она проще с уровнем не становится, только сложнее (т.к. заменяется низкоуровневой семнатикой, котораявозможно сложнее). Тот же LLVM IR - очень сложный, намного сложнее луа.

А как раз эффективнее всего это самое тяжеловесное делать ПОСЛЕ специализации. Всякий агрессивный constant propagation, например, основанный на нем DCE, loop invariant motion, loop fusion, векторизация (само по себе очень тяжелая задача) и тому подобное.

Так большая часьт перечисленных оптимизаций _и есть_ специализация, лол.

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

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

Идиот. Мы перенесли код из одной функции в другую. Как от этого изменится семантика программы в целом?!?

Кто тебе сказал, что эту функцию не вызывают в других местах?

Идиот. Возможных эффективных оптимизаций не так много.

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

А ты и в динамике этого не предскажешь. Поэтому в любом случае руководствуемся эвристиками.

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

А сколько эффективных трассирующих жытов ты знаешь?

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

А это утверждение ты каким пальцем и из какой жопы выковырял?

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

Кто тебе сказал, что не используется?

У меня ВЕСЬ код. Я знаю все про использование каждой из функций. И в крайнем случае я любую из них могу скопировать.

Ну так покажи компилятор, который сдублирует, какие проблемы?

Вот как только увижу эффективный жыт, так сразу.

2^10^10? генерируй.

Идиот. Эффективных для оптимизации вариантов хорошо если единицы. Для большинства случаев же их и вовсе нет.

А как ты будешь определять какой из специализированных инстансов применять вот в этом конкретном случае? Насуешь кучу проверок? Охуенная оптимизация, чо. Это говно в результате будет работать медленнее, чем оптимизированный код, лол.

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

Специализация - это развитый вариант инлайнинга, более ничего. Она делается очень быстро и просто.

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

потому что нет никакого способа оценить эту «эффективность».

Да-да-да, в компиляторах вообще никаких оптимизаций нет, потому что нет способов оценить эффективность результата. Ты больше не пей этот метанол.

Так большая часьт перечисленных оптимизаций _и есть_ специализация, лол.

Дебил. Найди, чем заменить polyhedral analysis, придурок.

Это блять факт известный любому человеку, который знает, что такое суперкомпиляция.

Да ты, похоже, выковыривая из жопы бред, пользовался даже не пальцем, а языком. Фу-фу-фу!!!

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

И какие же? Специализация константного аргумента функции? Абстрактная интерпретация? Да насрать тут на семантику.

Ну и да - никаких сайд-эффектов.

И сайд-эффектны никак не могут помешать.

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

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

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

Идиот. У нас есть эта функция. И из ее определения домен и выводится.

У меня ВЕСЬ код. Я знаю все про использование каждой из функций. И в крайнем случае я любую из них могу скопировать.

Замечательно, покажи компилятор, который так делает.

Вот как только увижу эффективный жыт, так сразу.

Я тебе уже показал и пруфы предоставил. Но для тебя это все заговор, да.

Идиот. Эффективных для оптимизации вариантов хорошо если единицы.

Да нету никаких «эффективных вариантов», ебанашка. С точки зрения компилятора они все одинаковые и выбрать какой-то из них нельзя.

В том и дело, что только для единичных случаев есть смысл такие оптимизации выносить.

В рантайме - для многих случаев, в компайлтайме -для единичных, да.

А жыт-то об этом и не знает, он-то всегда будет специализировать, для всех трейсов.

Он специализирует для «горячих» трейсов. При чем специализирует то, что статически специализировать возможности нет.

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

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

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

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

Найди, чем заменить polyhedral analysis

Зачем его заменять?

Я сказал - эффективных. Вот когда твои говноджыты хотя бы немного догонят банальный компилятор Си с минимальными оптимизациями

Они обогнали, что дальше?

У нас есть эта функция. И из ее определения домен и выводится.

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

Они обогнали, что дальше?

Лжешь. Только подлые свиньи могут так упорно лгать.

С оригинальным доменом, который выводится из определения, ничего сделать нельзя - функция специализированная на этом домене это и есьт сама наша оригинальная функция

Придурок. Если у нас где-то в коде есть условие, if (f(arg)) {говно} else {другое говно}, то мы можем раскрутить в обратную сторону определение f, и вывести, при каких значениях arg оно true, а когда false. Если говна много, то специализация имеет смысл, и вынос проверки вовне функции оправдан.

Зачем его заменять?

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

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

Про свой собственный пример с even придурок уже забыл. Занятно.

Я тебе уже показал и пруфы предоставил. Но для тебя это все заговор, да.

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

Давай, напиши функцию LOOP. Ну или хотя бы COND.

(defun my-cond (form &optional (env nil))
  (when (cdr form)
    `(if ,(caadr form)
         ,(cadadr form)
         ,(my-cond `(,(car form) ,@(cddr form)) env))))

Че? Это что за крякозябры вообще? Твой cond это недомакрос, а не функция. Он не будет работать.

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

Это что за крякозябры вообще?

Общелисп?

Твой cond это недомакрос, а не функция.

Функция. #'my-cond => #<FUNCTION MY-COND>

Он не будет работать.

Почему?

Компилятор - gcc с -O3 и -flt (ну и с другими флагами можно поиграться). Только не совсем дублирует. Просто встраивает, анализирует и т.п. Очень хорошо справляется.

-flto

Ну и что выдаст (my-cond ((> a b) 1) ((< b c) 2))?

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

Лолшто? Ты спросил mv о _его_ проекте, он тебе ответил. Что тебя не устраивает? Проекты на Лиспе ничем принципиально не отличаются от проектов на любом динамически типизированном языке. Хочешь саксесс сториз - иди на сайты производителей Лисп-систем.

А самый успешный лисп-проект, с тысячами разработчиков и миллионами пользователей - это Emacs.

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

Лжешь.

Я привел пруфы.

мы можем раскрутить в обратную сторону определение f, и вывести, при каких значениях arg оно true, а когда false.

Нет, не можем. Это алгоритмически неразрешимая задача.

И даже если вдруг сможем - что это даст? Да ничего. Все равно придется ставить предикат на аргумент f, что только замедлит программу.

Лживая ты скотина! Не было ни единого пруфа. Ссылка на визг какой-то другой свиньи за пруф не считается.

Ну вот видишь, тебе пруфы приводят, а ты в ответ: «это все заговор!!11 Ты лживая скатина!! кококо!!11».

Про свой собственный пример с even придурок уже забыл. Занятно.

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

Т.е., грубо говоря, инлайним функцию

Ты все функции заинлайнишь? А ничего что это сделать нельзя? Компилятор только некоторые функции инлайнит, если ты не знал.

Ну теперь покажи где он сдублирует код.

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

В CL defun это такой макрос который упрощает связывание символов (по symbol-function) с лямбдами или рекурсивными функциями (из labels). Например, defun выше можно упрощённо заменить на код из одних специальных форм и функций:

(labels
    ((rec (form &optional (env nil))
       (if (cdr form)
           (list (quote if)
                 (caadr form)
                 (cadadr form)
                 (rec (cons (car form) (cddr form)) env))
           nil)))
  (funcall (function (setf symbol-function))
           (function rec)
           (quote my-cond-function)))

так что теперь с символом my-cond-function связана рекурсивная функция и его аппликации/funcall/apply будут отрабатывать на стадии выполнения соответсвующим образом:

(type-of (function my-cond-function))
;; FUNCTION

(my-cond-function '(__ ((> 1 2) 1) ((< 1 2) 2) (nil 3)))
;; (IF (> 1 2)
;;     1
;;     (IF (< 1 2)
;;         2
;;         (IF NIL
;;             3
;;             NIL)))

(eval (my-cond-function '(__ ((> 1 2) 1) ((< 1 2) 2) (nil 3))))
;; 2

Аналогично - defmacro это макрос который упрощает связывание символов (но уже по macro-function) с такими же лямбдами и рекурсивными функциями:

(funcall (function (setf macro-function))
         (function my-cond-function)
         (quote my-cond-macro))

символ my-cond-macro в макро-аппликациях будет вызывать функцию my-cond-function уже на стадии раскрытия макросов:

(type-of (macro-function 'my-cond-macro))
;; FUNCTION

(my-cond-macro ((> 1 2) 1) ((< 1 2) 2) (nil 3))
;; 2

(macroexpand-1 '(my-cond-macro ((> 1 2) 1) ((< 1 2) 2) (nil 3)))
;; (IF (> 1 2)
;;     1
;;     (IF (< 1 2)
;;         2
;;         (IF NIL
;;             3
;;             NIL)))

(funcall (macro-function 'my-cond-macro) '(my-cond-macro ((> 1 2) 1) ((< 1 2) 2) (nil 3)) nil)
;; (IF (> 1 2)
;;     1
;;     (IF (< 1 2)
;;         2
;;         (IF NIL
;;             3
;;             NIL)))

Стандартный cond это тоже такая функция:

(type-of (macro-function 'cond))
;; FUNCTION

(funcall (macro-function 'cond) '(cond ((> 1 2) 1) ((< 1 2) 2) (nil 3)) nil)
;; (IF (> 1 2)
;;     (PROGN 1)
;;     (COND ((< 1 2) 2) (NIL 3)))

Аналогично и для макросов defvar/defparameter и define-symbol-macro (другие places/locations и уже не только функции в качестве связуемых).

Если взять любой staged ML или TH (и F# если бы они доделали глобальный сплайс), то там будет точно так же, только явно, так как функции-функции и функции-макросы отличаются сигнатурами и спайсить на мета-стадии получится только функции-макросы (потому что у них сигнатура подходящая), то есть нет смысла их как-то разграничивать - всё будут обычные функции.

(my-cond-function '(__ ((> 1 2) 1) ((< 1 2) 2) (nil 3)))

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

Ну вот видишь, тебе пруфы приводят

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

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

Может, придурок. Элементарный случай-то. Внутренний цикл с большими границами и функция, которая доказуемо loop invariant. Тут даже от стоимости проверки ничего не зависит, поскольку она уже и так внутри цикла.

Ты спросил mv о _его_ проекте, он тебе ответил.

Он свой проектишко приводил в ответ на мой общий (и, кстати, риторический) вопрос о существовании промышленных проектов на говнолиспе. Своим ответом он только подтвердил мой тезис, за что ему искренние спасибки.

Хочешь саксесс сториз - иди на сайты производителей Лисп-систем.

Тут над этим бредом уже столько раз народ смеялся, что даже как-то не хочется к этому возвращаться. Я не Кука, мне это не интересно.

А самый успешный лисп-проект, с тысячами разработчиков и миллионами пользователей - это Emacs.

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

ты без quote давай

(my-cond-macro ((> 1 2) 1) ((< 1 2) 2) (nil 3))

Видишь где-то определение my-cond-macro? Его нет, потому что my-cond-macro это ни что иное как my-cond-function на нужной стадии.

Тут товарищ распинался, что напишет функцию, полностью эквивалентную макросу.

Ну дык любой макрос это просто функция - (macro-function 'любой-макрос), она с AST работает во время мета-стадии.

Исторически в древних лиспах так и велосипедили - делали quote, функции (стадии выполнения) и eval, потом эта машинерия (quote и eval) спряталась в экспандере, мета-стадия была явно выделена вместе с разграничением символов по функциям (стадии выполнения) и макросам (функциям стадии раскрытия). Хотя кое-кто эту историю проходит снова, picolisp, например.

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

На Си там написана Лисп-машина. Можешь сравнить объем Си-кода с объемом elisp-кода.

Видишь где-то определение my-cond-macro?

Ты плохой, негодный фокусник. Как не называй, а это все равно макрос. А макросы - фу-фу-фу, какашка.

Ну дык любой макрос это просто функция

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

проектишко
Тут над этим бредом
маргинальная игрушка для ламерья.

Что-то ты сдуваешься.

Тут товарищ распинался, что напишет функцию, полностью эквивалентную макросу.

И надо заметить, что даже без всяких стадий он бы мог написать cond как ленивую функцию. loop - уже нет. Пришлось бы писать пару функций loop : ... -> Expr и eval : Expr -> ... которые бы работали в рантайме (как это сейчас в F# делают).

А макросы - фу-фу-фу, какашка.

Статически типизированные макросы это почти мейнстрим (Scala, например).

С ними можно реализовать, например, type safe printf. Ну и кучу других вещей которые в язык никак иначе не всунуть - только писать транслятор МойDSL -> НашЯзык и потом компоновать во время раздельной компиляции, а если это МойDSLВШаблоннуюПеремежкуСНашимЯзыком -> НашЯзык и нужна интерпортабельность, то скорее придумаешь какое-то решение без компилируемых eDSLей, чем станешь так делать.

Вот только функция это не макрос.

Да, любой макрос - функция, но есть функции не макросы.

что функции могут все то же самое, что макросы

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

макросы ничуть не хуже функций

А вот при наличии стадий макросы это просто другого (специального) рода функции которые нужны совсем для других целей нежели обычные функции времени выполнения - для реализации компилируемых eDSLей.

Зачем же все? LTO, в том числе, позволяет инлайнить то, что на этапе компиляции заинлайнить нельзя, обо всех функциях речь не идет. Но оптимизатору доступны все функции, что в сочетании с анализом потоков исполнения и пр., дает возможность принять весьма неплохие решения. Так, он хорошо встраивает виртуальные вызовы, если это выгодно и пр. Хотя казалось бы, это можно делать только в jit. Да, потенциально у jit'а больше возможностей по анализу и выбору оптимизаций, но его работа требует времени. И это тоже надо учитывать. В итоге хороший компилятор с LTO построит более эффективный код, чем код, созданный jit, + код jit-компиляции.

Т.е. да, код, построенный jit'ом, потенциально эффективнее, если бы работа самого jit'а была бы бесплатной. Но это не так, как ты понимаешь.

Кроме того, не забываем об libjit и llvm, которые смогут работать с байткодом, полученным от компилятора уже после нормальных оптимизаций, в том числе и LTO(по крайней мере частичных).

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

Это печально, на самом деле. Но факт.

D и Go не оправдали себя. Надеюсь вота теперь на Rust.

В scala таки запилили макросы? Вроде не было, кода я смотрел.

http://scalamacros.org, http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Reflection-and-Compi.... Есть в RC, будет в следующем выпуске (2.10).

Вот если еще psikh скажет, что уверовал в Господа Бога нашего Иисуса Христа - это будет бомба! :)

Ну православного срача нам тут еще не хватало...

Мутабельные состояния только в твоей голове.

В самолёт загрузили 100 тонн мяса. Самолёт остался тем же, нового самолёта не создалось.
Маша купила в магазине мясо, принесла домой и пожарила. Мясо осталось тем же, нового мяса не создалось.
Вася покрасил холодильник в чёрный цвет. Холодильник остался тем же, нового холодильника не создалось.
Мойша снял со счёта 1000 шекелей. Счёт остался тем же, нового счёта не создалось.

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

В самолёт загрузили 100 тонн мяса. Самолёт остался тем же, нового самолёта не создалось

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

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

пришло мясо, вышло пожаренное мясо, какая чистая функция. Информация о мясе, кстати, нам может еще пригодиться, если мы, скажем, пардон, обкакались, зачем её менять?

Вася покрасил холодильник в чёрный цвет.

пришла мама и заставила гота Васю вернуть все как было. Куда вы дели информацию о предыдущем цвете холодильника?

Мойша снял со счёта 1000 шекелей. Счёт остался тем же, нового счёта не создалось.

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

Дак, это давно известный на ЛОРе факт, что я лиспом на хлеб/двухподвес/Вольво (две) зарабатывал.

Так ты не благодаря лиспу зарабатывал, а вопреки. Если бы владел более современными, мощными языками, заработал бы на порядок больше. Ты серьезно не знаешь, сколько зарабатывает Java senior/lead developer? Java-специалисту топ-класса просто не придет в голову хвастаться на форуме тачками и шмотьем.

а я облачусь в велоброню, выйду из двухэтажной половины дома, поставлю двухподвес на Вольво

Лол, съемные полдома, велошмотки, китайский велосипед и подержаные тачки в кредит. И все это потреблядство - вершина стремления лисперов?

Я, кстати, давно заметил, что у тебя есть пунктик - икра. Это очевидным образом свидетельствует о том, что сего продукта тебе в детстве не доставалось (т.е. родители нищебродствовали), и у тебя развился комплекс. Сегодня ты пытаешься его компенсировать путем отъезда за границу, приобретения техники и автомобилей, шмоток и жрачки.

Но в душе ты все равно остаешься совковым школьником-нищебродом.

Код помедленнее генерит, плюс некоторые товарищи пишут библиотеки под SBCL-only.

Лол, вот это труЪ энтерпрайз! Переносимость и производительность!

И вы после этого взбугурчиваете от того, что лисп потерпел фиаско и был отвергнут индустрией.

На жабе можно зарабатывать деньги - на лисе можно зарабатывать деньги. Пока что все ровно идет.

Ровно идет, это точно. Только Java и С/С++ занимают первые места в TIOBE, а лисп - 18-е. И весь софт в мире написан на Java/C/C++/FORTRAN, а не на лиспе. А так лисп ровно идет, ага.

На свалку истории.

КОБОЛ еще забыл. Даже на нем кода написано больше, чем на общелиспах-ракетках-кожурах, вместе взятых. И он до сих пор стабильно и надежно обслуживает ж/д-рейсы и авиаперевозки.

А что обслуживает лисп?

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

Ну хорошо. Создали накладную на сборный груз. По мере включения грузов в рейс... каждый раз берем новый лист бумаги, переписываем в него все предыдущие грузы, дописываем новый, а старую накладную сжигаем!!!

Или, может, все-таки дописываем новые строчки в ту же накладную, а?