Создатель Python разочарован в Scala

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

И, кстати, основной поинт, который лисперы пытаются донести до низших, это всего лишь то, что не знать лисп стыдно, и стыдно не использовать его там, где это уместно. При этом, точно так же стыдно не знать Си, стыдно не знать Жабу, стыдно не знать Пролог, стыдно не знать ML, и т.п.

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

>Низшие истошно защищают своё право не знать.

Во! Спасибо за красивую формулировку.

mv, лучше окстись и не позорься. Лисп реально слил в этой задаче из-за бигнумов. Я не сравнивал лисп и С, но я сравнивал свой (правильный) вариант и вот этот вариант

http://www.linux.org.ru/view-message.jsp?msgid=3277883#3279889

который привёл ник "не к ночи будь помянут". Последний просто-напросто неправильно считает (что и должно получаться у такого ника). Да, зато он делает это очень быстро :)

Если есть ещё какие-то варианты, то я буду рад ссылке.

А, справедливости ради, неупоминаемый ник, автор того неправильного теста, сам же и указал, в чём проблема, и что сумма может не попасть в fixnum. При этом, поскольку safety 0, переполнение пройдёт незамеченным и получится неправильный результат. Также он провёл тестирование на 64-разрядной версии и получилось быстро.

> Докажи, что ты его не от балды нарисовал?

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

> Я доказал, что график неумело сфальсифицирован.

Вы доказали только то, что Вы не владеете методологией бенчмаркинга, а также невнимательно читаете. Чуть выше было показано, что Ваш результат (1.6 раз) специфичен только для платформ, на которых SBCL поддерживает 64-битные целые.

Вы же на основе измерений в одной точке (300 Мб) и на одной платформе (x86/64) делаете выводы об общности. Со статистической точки зрения Ваш результат не представляет ценности.

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

>Чуть выше было показано, что Ваш результат (1.6 раз) специфичен только для платформ, на которых SBCL поддерживает 64-битные целые.

А ваш? Вы проверили правильность результата?

> mv, лучше окстись и не позорься. Лисп реально слил в этой задаче из-за бигнумов.

Ты думаешь, что си лучше с бигнамами работает? :)

В равных условиях (когда результат помещается в поддерживаемое машинное представление) sbcl генерит практический такой же. Разница лишь в том, что в лиспе нельзя напрямую работать с untagged значениями. К слову, если вектор будет содержать fixnum'ы, то скорость будет одинаковая (но памяти больше жрать будет).

> Почему тогда у меня код на Лиспе всегда получается гораздо короче (и понятнее для даже нелисперов), чем аналогичный по функциональности не только на Жабе, но даже и на OCaml?

Я полагаю, что дело в Вашей некомпетентности в Java и OCaml. Либо Вы решаете исключительно задачи из того узкого класса, где Лисп проявляет себя хорошо (DSL/eDSL). Хотелось бы взглянуть на примеры кода.

> В 1.6 раз

Это ложь. 1.6 раз в частном случае (на специальной платформе и со специальными твиками). В общем случае проигрыш в 6 раз и более.

> на задаче, для которой Лисп никто из лисперов использовать не станет

Это ложь. "Лисперы", отметившиеся в данном топике, настаивали на обратном - на превосходстве Лиспа в абсолютно всех областях программирования. Это было убедительно опровергнуто экспериментом.

> на самом деле мы просто умные

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

> Это ложь. "Лисперы", отметившиеся в данном топике, настаивали на обратном - на превосходстве Лиспа в абсолютно всех областях программирования. Это было убедительно опровергнуто экспериментом.

Пруфлинк на _моё_ такое утверждение?

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

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

В последнее время начали наконец звучать здравые тезисы о том, что область эффективного применения Лисп одна - создание DSL/eDSL, что "элитарность" лисперов - дутая, что Лисп ничуть не лучше и не хуже других языков, со своими плюсами и минусами.

Пока это не станет ясно каждому, моя миссия будет продолжаться.

> Это ложь. 1.6 раз в частном случае (на специальной платформе и со специальными твиками). В общем случае проигрыш в 6 раз и более.

Давайте возьмём расчёты в bignum, си точно так же всосёт. Даже если будете использовать gmp, то порнография в синтаксисе всё равно появится. Давайте, посчитаем астрономические величины?

>В общем случае проигрыш в 6 раз и более.

Это в том общем случае где С не заметит переполнения и считает неправильно зато быстро?

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

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

> Пока это не станет ясно каждому, моя миссия будет продолжаться.

Жесть! Религиозные фанатеги на лоре! Самая безпроигрышная позиция - как бы не сложилось он либо мессия либо мученик:)

> Это в том общем случае где С не заметит переполнения и считает неправильно зато быстро?

У него задачи с производства. На производстве регистры не переполняются. Переполнения регистров на производсте запрещены приказом руководства.

> Цель моя проста - она исключительно просветительская. Сложился стойкий миф о Лиспе как об элитарном мегаязыке с безграничными возможностями, моя задача - его развеять.

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

java
C++
prolog
python
ocaml
sql
tcl
pascal
ruby

Я бы рекомендовал Вам ознакомиться с этими языками и с лиспом тоже. Тогда сможете сравнить. А пока что Ваша постановка задачи звучит как заявление религиозного фанатика.

Не надо путать сравнительное богатство возможностей и превосходство во всех отношениях и на всех задачах. И не забудьте, что пока что мы разобрали всего лишь ОДНУ задачу и всего лишь ОДНУ (не самую лучшую) реализацию лиспа. Лучшей реализацией лиспа считается Allegro CL.

> Лучшей реализацией лиспа считается Allegro CL.

Лучшей в каком плане? Явно не в скорости готового кода, имхо.

> Давайте возьмём расчёты в bignum

Давайте не будем брать расчёты в bignum, для данной задачи это не обязательно. Причём Си справится с задачей за счёт поддержки типа "64-битное целое" на любой платформе, а Лисп либо всосёт, либо потребует оборудования бОльшей разрядности.

Платформа, не поддерживающая фиксированные целые независимо от процессора, не может всерьёз рассматриваться как платформа для вычислительных задач. Вы до сих пор утверждаете, что Лисп пригоден для чего-то ещё, кроме DSL? Советую Вам прислушаться к мнению более трезвомыслящих коллег, и сложить оружие.

На сообщение (http://www.linux.org.ru/jump-message.jsp?msgid=3285539&cid=3289015) из топика "Знатокам Лиспа-3" отвечу здесь, ибо топик канул в лету.

> И сам я этим занимаюсь, 90% времени ковыряюсь в старинном коде на Фортране, и потом оставшиеся 10% пишу несколько строчек на Лиспе, этот код заменяющие.

Я полагаю, что Вы лжёте. Но "несколько строчек на Лиспе" вполне могут быть доказательством, приведите их. Почему я полагаю, что Вы лжёте? Потому что "унаследованный код на Фортране" - это, как правило, вычислительные алгоритмы (числодробильня), где Лисп показывает себя абсолютно непристойно. Пристойно он себя показывает только в одной-единственной области - написании DSL- и eDSL-языков, но вряд ли в чью-то больную голову пришло бы создавать DSL'и на Фортране. Спасибо.

Не увиливай. От bignum'а ты, значит, тоже отказываешься?

Дать свою оценку вы не можете, т.к. не знаете лиспа.

> Это в том общем случае где С не заметит переполнения и считает неправильно зато быстро?

Это в том случае, когда программистом будет обосновано применение типа данных (uint64), и доказано, что в данной задаче переполнения не возникнет. Да, это потребует от программиста мозгов и знания математики. Вас это удивляет?

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

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

> Жесть! Религиозные фанатеги на лоре! Самая безпроигрышная позиция - как бы не сложилось он либо мессия либо мученик:)

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

> Не увиливай. От bignum'а ты, значит, тоже отказываешься?

Ни в коем случае. На задаче, где использование bignum'ов обоснованно и необходимо, Лисп сольёт Си в свои честные 1.6 раза. Там же, где на Си может быть успешно применён int64, не поддерживаемый Лиспом, Лисп вылетит в трубу.

> Ни в коем случае. На задаче, где использование bignum'ов обоснованно и необходимо, Лисп сольёт Си в свои честные 1.6 раза.

Обоснования?

> Там же, где на Си может быть успешно применён int64, не поддерживаемый Лиспом, Лисп вылетит в трубу.

Я рад, что у вас появился новый фетиш.

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

То есть лямбда-исчисления Черча это антинаучный бред? Ого к чему мы уже дошли.

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

Алелуя!

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

К вопросу о сложности/простоте синтаксиса Лиспа.

Собственно, синтаксиса, как такового, у Лиспа и нет. То есть присутствует одна-единственная конструкция - скобки, ну плюс ещё разные квотирования. При этом всё остальное, даже элементарщина типа арифметики - ложится на стандартную библиотеку, состоящую из тысяч функций с длинными плохозапоминаемыми именами, например, hash-table-rehash-threshold, internal-time-units-per-second, least-positive-normalized-double-float, load-logical-pathname-translations, simple-condition-format-arguments, update-instance-for-redefined-class и так далее. (Пруфлинк: http://www.lispworks.com/documentation/HyperSpec/Front/X_AllSym.htm)

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

> чтобы решение той задачи использовало int64?

Для этого придётся написать руками всю арифметику для int64 как для пользовательского типа. (То, что в Си является встроенной в язык фичей.) Это преподносится нам как "язык с богатейшими возможностями".

> Я рад, что у вас появился новый фетиш.

Смешно слышать это от человека, который половину топика выносит всем мозг своим eval'ом.

> Для этого придётся написать руками всю арифметику для int64 как для пользовательского типа. (То, что в Си является встроенной в язык фичей)

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

> То есть лямбда-исчисления Черча это антинаучный бред? Ого к чему мы уже дошли.

Вы подменяете понятия. Была проведена аналогия между "антинаучным бредом" и оголтелыми заявлениями о тотальном практическом превосходстве Лиспа во всех областях программирования. Не надо впутывать в это мракобесие Алонзо Чёрча и его лямбда-исчисление.

Вот это:
> сам с лиспом не знаком

не даёт Вам права говорить вот так:
> ну что за бред

В случае с макросом всё равно придётся так или иначе реализовывать всю арифметику самостоятельно. Использование кодогенерации Си решит задачу, но ещё раз подчеркнёт несостоятельность Лиспа per se, и необходимость костылей.

Вы бы ещё предложили ассемблерные вставки использовать.

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

Да дело-то не в использовании какого-то хитрого типа. Лисп - это язык с автоматическим управлением памятью. Это значит, что к каждому объекту прицепляется тэг, идентифицирующий тип объекта. Самым низкоуровневым целочисленным типом, доступный программисту, является fixnum. В реализации CMUCL и его форков (SBCL, Scieneer), fixnum - обычное машинное слово (4 байта на x86, 8 на x86-64), в котором младшие 3 бита заняты тэгом. Если считается "родная" fixnum-арифметика, то скорость такая же, как и в других языках. Даже таких низкоуровневых, как Си. Но в данном примере ведётся обсчёт массива с числами в машинном представлении, которые нужно приводить к типу fixnum. Вот на приведение как раз скорость и теряется.

Какого качества тупая трансляция в сишный код получается - это можно глянуть у GCL/ECL.

На анонимуса, мнящего себя Джордано Бруно, серьёзно вестись не стоит, т.к. он в Лиспе ничего не понимает. С одной стороны, как только 64-битного целого в си перестанет хватать, там начинается страшный геморрой (он это называет использованием математических скиллзов), а лисп автоматический переходит на использование бОльшего типа. С другой стороны, я на ассемблере могу написать более быстрый код, чем генерирует gcc. Ассемблер x86 знаю хорошо, поэтому мне совершенно фиолетово, на каком его подвиде писать: нативном или кросс-платформенном. В реальной жизни такие задачи, естественно, на ассемблере решать не буду. И десять раз подумаю, нужен ли тут Си с его перевесом всего лишь 50% в самом примитивном случае.

А ещё можно вспомнить страшилки, как в районе 4.1 или 4.2 у gcc сломался кодогенератор, и он перестал использовать регистры r8-r15 с соответствующим результатом в плане скорости.

> Для этого придётся написать руками всю арифметику для int64 как для пользовательского типа. (То, что в Си является встроенной в язык фичей.) Это преподносится нам как "язык с богатейшими возможностями".

Ты даже не понимаешь, какую ахинею несёшь. Если бы ты не был таким упёртым занудой, мне бы тебя даже стало немножко жаль.

> Вы бы ещё предложили ассемблерные вставки использовать.

почему нет?

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

> Вы подменяете понятия. Была проведена аналогия между "антинаучным бредом" и оголтелыми заявлениями о тотальном практическом превосходстве Лиспа во всех областях программирования.

Пруфлинк-то на эти оголтелые заявления дадите?

> Вы бы ещё предложили ассемблерные вставки использовать.

А что не так? Если этого требует производство? Давайте опять померяемся: вы на последней ревизии ANSI C пишете, скажем, конвертер RGB565->RGB32, а я его на ассемблере?

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

Ага, значит я просто заблуждался насчёт причины, спасибо за разъяснение :)

> Какого качества тупая трансляция в сишный код получается - это можно глянуть у GCL/ECL.

Хм.. интересно, а почему хаскель так эффективно переводится в сишный код? Лисп теряет в скорости за счёт динамической типизации?

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

>Была проведена аналогия

Вот эта чтоли?

> Не надо быть поваром для того, чтобы понять, что мясо протух

Да вы просто гений аналогии!

> Хм.. интересно, а почему хаскель так эффективно переводится в сишный код?

Как эффективно? :) Напиши решение этой же задачи на Хаскелле и сравни результаты.

> Лисп теряет в скорости за счёт динамической типизации?

За счёт приведения машинного представления в лисповый.

> кстати, а нет ли в лиспе аналога сишного массива?

Его и использовали.

> не даёт Вам права говорить вот так:

он умеет сводить к противоречиям отдельные тезисы. А вы что против?

>> Хм.. интересно, а почему хаскель так эффективно переводится в сишный код?

> Как эффективно? :) Напиши решение этой же задачи на Хаскелле и сравни результаты.

так, что хаскель оказывается в первых строках на shootout :) Слежу за топиком, думал уже о том, чтобы написать решение, но руки пока не доходят. Завтра попробую :)

> За счёт приведения машинного представления в лисповый.

Так, стоп. Я имел в виду под аналогом на си именно представление в памяти как последовательность 32битных чисел, не разбавленную счётчиками ссылок, указаниями на тип и чем либо ещё (не считая указания этих данных один раз на весь массив)

> Так, стоп. Я имел в виду под аналогом на си именно представление в памяти как последовательность 32битных чисел, не разбавленную счётчиками ссылок, указаниями на тип и чем либо ещё (не считая указания этих данных один раз на весь массив)

(make-array xxx :element-type '(unsigned-byte 8)) создаёт c-like массив, содержащий xxx элементов типа, аналогичного unsigned char в C. Но это не отменяет того факта, что вся арифметика хочет аргменты минимум с типом fixnum.

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

> Ага, значит я просто заблуждался насчёт причины, спасибо за разъяснение :)

Камрад mv не объяснил самого главного. Потеря скорости на преобразование невелика. Веселье начинается, когда Лисп обламывается об отсутствие нативного типа int64 и автоматически начинает использовать arbitrary-precision integer, в то время как Си спокойно продолжает вычисления с int64 независимо от платформы.

Это приводит к такой картинке:
http://s1.ipicture.ru/uploads/081127/vMOdAPU4Rf.png
(источник: http://www.linux.org.ru/jump-message.jsp?msgid=3285539&cid=3286540)

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

И да, конечно же, не слушайте анонимуса, возомнившего себя Джордано Бруно: все цифры он выдумывает из головы, Лиспа не знает, в сфере high-performance computing не работал несколько лет, корпоративных информационных систем не писал, университетов не заканчивал, и так далее.

> Пруфлинк-то на эти оголтелые заявления дадите?

То есть Вы уже сами открещиваетесь от этих заявлений, и готовы признать, что Лисп не годится для чего-либо, отличного от написания DSL?

> Но это не отменяет того факта, что вся арифметика хочет аргменты минимум с типом fixnum

ага, опять затыка не там, где я полагал :) ясно, спасибо :)

> То есть Вы уже сами открещиваетесь от этих заявлений, и готовы признать, что Лисп не годится для чего-либо, отличного от написания DSL?

Ты не отходи от темы, давай пруфлинки.

>> Вы бы ещё предложили ассемблерные вставки использовать.

> А что не так? Если этого требует производство?

Так и запишем: Лисп без ассемблерных вставок - пшик.

Клоун.