Про LISP

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

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

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

по поводу http://shootout.alioth.debian.org/ сравните лучше с FreePascal-ем (одна из вещей которая действительно радует, написанным кстати европейской молодежью), ява сливает на 99% с чудовищным стартапом, и про память тоже лучше не упоминать

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

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

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

В новостном топике проскакивала "пенисомерка", показывающая как java выигрывает от jit-компиляции, "упрощая" вызовы единственных виртуальных интерфейсных вызовов, но при этом оставляя прозрачную возможность при наращивании функционала возвращаться к полноценному наследованию. Т.е. оптимизация во время компиляции (те-же О3 или вообще opt из LLVM - посмотрите количество возможных оптимизаций) в принципе ортогональна jit-оптимизации. Но нужны и та и другая. А отказ от "стероидных оптимизаций" - это откат к асму. "Забудьте" его там где он не нужен.

> ява сливает на 99% с чудовищным стартапом...

что говорит о трудностях в применении shell-подобного jvm-скриптинга (много мелких утилиток очень часто вызываемых) но ничего не говорит о скорости работы самого кода как такового. Лучше бы оставили тайминг стартапа отдельным тестом, а остальные тесты проводили бы из кода, а не при помощи `time`

>> ...Если даже самые высокоуровневые дают 30%,...

> Даже странно, что лисперы сошлись на всего лишь 30%. Обычно они под 90 требуют...

От задачи очевидно зависит, равно как и от метода реализации. Если на лиспе воротить C-подобные циклы (благо лисп это позволяет) там, где можно и нужно map*/hash-table/find, то и прироста никакого не будет, разве что в тормозах. Вполне можно измыслить также задачу, которая именно с помощью циклов реализуется наиболее просто, то опять таки на ней принципиально никакого ощутимого прироста не случится. Только вот оба эти случая в real life несомненно будут "притянуты за уши".

> Разработка и кодирование на едином языке (за что лисперы обычно ратуют) есть ИМХО очевидный нонсенс.

А если подумать, почему приходится на разных?

> ИМХО LISP -- нормальный язык для неторопливой работы со списками.

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

> Всякие ФП ООП и метапрограммирование

А если для частного случая это не так, то и "всякие" годятся. Полюбому это лучше чем недоООП во всяких прочих.

ты че? какой смоллтолк? иди учись, студент, лисп -- 50 года, симулы и близко не было

> иди учись, студент, лисп -- 50 года, симулы и близко не было

Прими винпоцетин, дед, Лисп - 1959 год, и где там OOP в Lisp 1.5? Симула67 - 1967.