CL быстрее прочих :)

Красота.

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

> Вначале это была библиотека на Perl. Потом из Perl выкинули всё ненужное.

Да ну? Авторы PHP другого мнения:

As more functionality was required, Rasmus wrote a much larger C implementation, which was able to communicate with databases, and enabled users to develop simple dynamic Web applications.

Однако вышел фэйл - ребятки просто не осилили переписать весь перл + свои велосипеды на C. Реализовали то, что нужно было для Web.

переписали и получился PHP

Ага, до сих пор переписывают, но получается хреново.

Qi II вполне себе родился и пожил. Qi III под названеием и новой платфомой пишется.

Почему так? Потому что автор очень старался открутить cвое творение от лиспа и затруднить взаимодействие. В протиположность CLOS интегрирована бесшовно и поэому успешна.

> Самое интересное, что то, что находится внутри query <@ ... @> является полноценным выражением на F#. Если бы значение db.Employees означало бы не базу SQL, а нечто соответствующее, то это выражение даже можно было бы исполнить как обычное выражение на F#. То есть, с одной стороны эта штуковина выражена «в терминах ПО языка реализации» (c), а с другой - это просто по-другому записанный SQL.

Это все таки записаный linq, а не SQL.

Описания F# реализации linq я , к сожалению, гуглом найти не смог. Так что чисто теоритически сделаю преположение что query <@ ... @> транслирует лишь некоторое подмножество F#, а не произволные выражения. То есть DSL использует часть терминов ПО идентичных или похожих на термины ПО языка реализации.

>В протиположность CLOS интегрирована бесшовно и поэому успешна.

«Так я не понял - что конкретно ты имела в виду?» (С)

Автор Qi, гнул пальцы что у него Лисп нового поколения. Qi полностью на CL, но автор всячески затруднял интеграцию и по сути написал новый язык. Но новый язык окался никому не нужным.

CLOS ведь по сути лиспу тоже перпендикулярен, но сделан как расширение.

Можно сказать, что лисп ориентирован на постояное расширение, в противовес написанию новых велосипедных языков.

>>> Зачем? Что в экономической ИС можно метпрограммировать? Тупую логику расчета, тривиальный интерфейс?

Ну-ну, в теме вы товаришь совершенно.

А конкретнее?

Примитивная логика и тривиальный интерфейс у быдлокодеров.

В нормальной системе описание предметной области, процессов и правил само по себе составляет свой собственный язык. А предметно-ролеориентировынй интерфейс несколько сложне 3 окошек проигрывателя. Другой вопос, что Enterpise-языки метапрограмирования поддерживают плохо и тяжело. Но данный тренд все равно лезит вперед и вновь изобретается кривой велосипед по причине не знания того же лиспа. Почему лезет? Потому что позволяет уменшить сложность и упростить сопряжение разных систем.

аааа, я просто не так понял «кто на ком стоял» =)

Ну из QiII лисп то можно было использовать... И даже микс можно было делать... Но выглядел он конечно совсем не «по-лисповски»

А Shen что-то пока никак не выкладывается...

> А Shen что-то пока никак не выкладывается...

Shen - moving from Common Lisp to LISP

FFUUU~
Ну почему не jvm? Почему не clr/dlr, в конце концов? То хоть бы какое-то будущее было, а не нытьё, что библиотек нет и смерть в агонии через полгода.

> То хоть бы какое-то будущее было, а не нытьё, что библиотек нет

и смерть в агонии через полгода.

Хм, а что ни так с библиотеками в CL?

> Ну почему не jvm? Почему не clr/dlr, в конце концов? То хоть бы какое-то будущее было, а не нытьё, что библиотек нет и смерть в агонии через полгода.

Эээ, а shen разве не будет сразу создан под разные платформы, в том числе и jvm?

А Shen что-то пока никак не выкладывается...

Что такое Shen? Опять что-то китаизм -> язык программирования от Марка Травера?

::Зевает:: А зачем метапрогра-а-ммно, когда можно и декла-а-ративно?

по причине не знания того же лиспа

И надо отметить, и то и другое в лиспе хреново...

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

Дык, поддай газу...

> Хм, а что ни так с библиотеками в CL?

Существует распространённое мнение (стереотип уже), что или много чего нет, или то что есть весьма плохого качества.
Скажите, как в CL обстоят дела с параллелизмом, поддержкой баз данных, сетевых протоколов, графических морд, ну и FFI в целом?

> Существует распространённое мнение (стереотип уже),

что или много чего нет, или то что есть весьма плохого качества.

Вот именно, что стереотип. Библиотек меньше, чем для Python, без вопросов, но в каком языке их больше, чем для Python?

Скажите, как в CL обстоят дела с параллелизмом, поддержкой баз

данных, сетевых протоколов, графических морд

Да нормально вроде. Только очень уж общие вопросы.

ну и FFI в целом

А c FFI лучше, чем где бы то ни было.

как и почему закончится любой спор с archimag-ом лично мне уже давно понятно ...

лучше свой предпоследний пост поясни, может чего и получится )

> как и почему закончится любой спор с archimag-ом лично

мне уже давно понятно ...

Я очень хочу знать чем и почему? ;)

> Вот именно, что стереотип.

Да нормально вроде.

А c FFI лучше, чем где бы то ни было.

А, ну это замечательно.

Кстати, я недавно написал продвинутый FFI.
http://github.com/Lovesan/virgil

> А c FFI лучше, чем где бы то ни было.

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

> Я очень хочу знать чем и почему? ;)
что ты! quicklisp же все еще бета, как ты можешь тратить время тут на это )

> Ясное дело, своих библиотек нету, тырят сишные через FFI.
у тебя конкретно много украли ?

В мануалах Интел есть отнюдь не все.

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

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

У Криса Касперски очень хорошая книга есть про опимизацию - там все хорошо описано, на конкретных примерах. Есть примеры, как скажем невыровненный счетчик просаживает производительность в разы.

> ::Зевает:: А зачем метапрогра-а-ммно, когда можно и декла-а-ративно?

1. бывает, что декларативные конструкции имеют некоторые неочевидные детали, которые становятся очевидны в случае знания (допустим метапрограммной) реализации

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

3. ну и текущие абстракции, наконец; я уже рассказывал, что по тормозному gprs у меня страница грузилась так долго, что в яндекс-деньгах успевал истечь таймаут авторизации :-)

А метапрограммирование значит серебряная пуля? И там все так кристально? По-моему как раз не.

> А метапрограммирование значит серебряная пуля? И там все так кристально? По-моему как раз не.

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

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

Кстати, в лиспе дела хреново обстоят и с тем и с тем.

> Кстати, в лиспе дела хреново обстоят и с тем и с тем.

Что бы делать такие выводы надо, по крайней мере, этот лисп знать. Кстати, языка с названием «лисп» уже давно нет.

За всю Одессу не скажу, но на моем личном фронте произошел серьезный фейл. ОЧЕНЬ неприятно, когда из-за неправльно поставленного quote в одночасье теряешь контроль над кодом проекта, правда ведь?

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

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

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

жаль что лисп дисквалифицировали в fannkuchredux

я как раз вчера к 5ти утра с температурой 38.5 натайпил кусок с++ чтобы не было вопросов насчет перформанса :D Разумеется жульничал и может не примут, но факт что elapsed <7 секунд на венде/msvc2010 c cpu=core2quad(2.5GHz). Мерять будут на linux/g++ так что немного послабее будет но не сильно.

так сказать на правах вброса.

> жаль что лисп дисквалифицировали в fannkuchredux

За что? Ссылку же.

>> жаль что лисп дисквалифицировали в fannkuchredux

За что? Ссылку же.

видимо за то что реализован другой алгоритм. Ссылка в исходном посте не устарела - лисп перекинули в «интересные альтернативные».

более того пока благородные доны спорили - империя (java) нанесла ответный удар (11.67 секунд против SBCL 12.90 секунд). Но ее тоже дисквалифицировали так как у них есть спец. правило запрещающее ручную раскрутку циклов.

http://shootout.alioth.debian.org/u64q/benchmark.php?test=fannkuchredux&l...

Java нанесла ответный удар и почему-то оба теперь в «interesting alternative» programs - что это значит?

А где ваш код на С++, я там что-то не увидел.

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

Кстати, в лиспе дела хреново обстоят и с тем и с тем.

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

а если есть что возразить давай на примере конкретного практически полезного кода

ОЧЕНЬ неприятно, когда из-за неправльно поставленного quote в одночасье теряешь контроль над кодом проекта, правда ведь?

А вы ставьте quote правильно!1 :)

>из-за неправльно поставленного quote в одночасье теряешь контроль над кодом проекта, правда ведь?

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

>А где ваш код на С++, я там что-то не увидел.

там премодерация. пройдет пару дней прежде чем они решат - я ж только засабмитил. Кроме того передо мной в очереди очередная атака SBCL на другой тест уже пару дней как отправленная.

Кроме того передо мной в очереди очередная атака SBCL на другой тест уже пару дней как отправленная.

http://paste.lisp.org/display/115655

Я же говорю - Алексей перешёл не просто к генерации кода, а к расширению компилятора своими примитивами и VOPами (раскрывающиеся в ассемблер) :) Скоро для каждого бенчмарка будет свой встроенный оптимизирующий компилятор.

> http://paste.lisp.org/display/115655

Жесть какая.

Жесть какая.

Это SSE под задачу на sb-ассемблере :)

Кстати, что интересно, при этом он пишет фактически такой код:

(defmacro adder (m)
  `(lambda (n)
     (+ ,m n)))

(defun main (n m)
  (funcall (eval `(adder ,n)) m))

У Норвига с Питманом в good-lisp-style есть пункт о том, что использование eval - это всегда повод задуматься. Почему не хрестоматийное:

(defun adder (m)
  #'(lambda (n)
      (+ m n)))

(defun main (n m)
  (funcall (adder n) m))

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

>Такого не бывает.

С макросами еще как бывает. ИЧСХ, выясняется это в рантайме. Хотя в CL с этим вроде бы попроще. А вот с Clojure... Конечно там главная проблема в том, что рабоать приходится с явскими объектами, а это накладывает отпечаток.

> Хотя в CL с этим вроде бы попроще. А вот с Clojure...

Хм, при чём тут вообще Clojure?

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

> С макросами еще как бывает. ИЧСХ, выясняется это в рантайме

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

и macroexpand +1

> но это значит только что нужно пилить замыкания в компиляторе, а не заменять их runtime-компиляцией

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

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