Common Lisp. Двадцатилетний зомби.

Забавный тезис, то же самое можно сказать с точностью до наоборот. ARM и MIPS - вполне современные процессоры и работают там, где POWER7 никогда не будет работать. Но вот одно забываете, как минимум mips могли бы сделать конкуренцию power7, думаю китайцы это очень скоро докажут.

> при чем тут lisp-2/lisp-1 ? TCO — удобная вещь

При том, что lisp-1 - это преимущественно функциональные языки, в которых рекурсия играет немалую роль, для lisp-2 - это не так критично.

> Современные реалии таковы что java аппаратно поддерживается а лиспы - нет.

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

Ты такой умный что мне вообще неочем с тобой говорить :)

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

Ну и зачем чушь нес, про какую-то там аппаратную поддержку Java? Для ARM для ускорения работы Java есть полуаппаратная трансляция инструкций JVM в инструкции ARM. Это делается исключительно по той причине, что платформа не потянет полноценный JIT. Трансляция байткодов макроподстановкой - вообще самый тупой и медленный вариант компиляции.

А ты - просто идиот, который ни хера не знает.

С таким знанием аппаратной части режима jazelle у себя в кащенке ты явно считаешься лучшим в мире хакером :)

Иди, почитай спеки на Jazelle, недоумок. Это именно что и есть макро-трансляция, недоумок.

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

> Иди, почитай спеки на Jazelle, недоумок. Это именно что и есть макро-трансляция, недоумок.

vsl?

недоумок

> При том, что lisp-1 - это преимущественно функциональные языки, в которых рекурсия играет немалую роль, для lisp-2 - это не так критично.

при чем тут критичность? ключевое слово _удобство_

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

Компилировать лисп в жавовский байт-код, очевидно же!

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

Кстати ни Java, ни LISP я не вижу сегодня как активно использующиеся.

> байт-кода лиспов

какой в попу байт-код лиспа? все нормальные лиспы генерят в нативный код. Иди фапай на свою жабку. Тут ты не в теме.

;;; Denver hodgman

> Кстати ни Java, ни LISP я не вижу сегодня как активно использующиеся.

У меня в проекте, «Kстати ни Java, ни Дотнет я не вижу сегодня как активно использующиеся».

;;; macias waivers

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

> Теперь ответь на свой же гениальный вопрос - каким образом ты собираешься использовать аппаратную трансляцию байт-кода java для для байт-кода лиспов ?

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

И все же объясни, недоумок, на хрена на «современных CPU» такая трансляция вообще нужна, если хватает ресурсов на полноценный JIT, или, еще лучше, если злобные копирасты не запрещают запускать машинный код?

> В случае с java, jazelle дает ускорения выполнения java кода в несколько раз

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

Jazelle ускоряет интерпретацию java, тупой ты недоумок. Но jazelle работает в разы медленнее чем та же самая java, скомпилированная в нейтив.

Баран - иди жуй дальше свою траву.

> В случае с jazelle просто взяли и создали процессор, который способен выполнять этот байт-код напрямую, без JIT

Jazelle не умеет выполнять байт-коды JVM напрямую. Он ничего не знает про GC и классы. Он просто позволяет немного быстрее интерпретировать некоторые отдельные инструкции JVM для работы со стеком. А это подойдет для любой стековой машины, включая даже Форт.

Баран, вообще-то, ты. Ты сказал чушь. Ты неграмотен. Тебя ткнули рылом в твою бредятину. Кто после этого баран, а, ничтожество?

>ни LISP я не вижу сегодня как активно использующиеся.
Вообще говоря, да. LISP(1.5) уже лет 40 нигде не используется.

> Хочу узнать подробнее о самых больших проблемах в Clojure.

мне лично clojure не сильно нравится, как язык. В нем нет поддержки ооп и моп, нет нормальной сигнальной системы, нет лучших возможностей для оптимизации кода, синтаксис менее униформен по сравнению с CL.

(1) ООП, как бы то ни было, дает неплохой code reuse и в некоторых ситуациях без него было бы тяжко (CAD, например), поэтому каждый раз приходится изобретать в том или ином виде ооп - или через замыкания, или через хэштаблицы и т.д. В этом отношении clojure очень напоминает лиспы 80ых годов - сначала там тоже не было никакого намека на ооп - лисп бы простым и элегантным, но именно необходимость ооп в сложных системах заставила сделать flavours, да и в CL сначала появилось наследование структур, а потом и полноценное ооп в виде CLOS. Да и удобство использования CLOS/MOP во многих случаях оставляет clojure далеко позади.

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

(3) Отсутствие ридер макр. На мой взгляд, их наличие частенько оплачивает все возможные недостатки. (4) Неуниформный синтаксис - неудобно в редакторе жонглировать разными скобочками :) Также режет глаз различие стилей именования переменных в лиспе и яве.

Ну а теперь о хорошем - в clojure многое сделано «правильно» - униформные sequences, autogensyming, auto destructuring, lambda macro, persistent data и прочее. Но главное, конечно, STM - писать многопоточные приложения в разы легче, чем с помощью семафоров, локов, кондишенов и прочего. Но опять-таки, все это может быть сделано в CL - синтаксический сахар делается с легкостью, а с многопоточностью посложнее, хотя и тут есть чем ответить - cl-stm - реализация stm модели, cl-muproc - реализация actor модели.

На мой взгляд, на данный момент, clojure использует, я бы даже сказал паразитирует, на серьезных библиотеках из jvm и их объектной моделе, и подавляющее большинство программ - это обертки вокруг java libs. Я не видел еще ни одного достаточно серьезного проекта на этом языке (хотя бы 30-40к строк). Сейчас, его ниша - это маленький скриптовый недоязычок, который очень хорошо и элегантно выглядит на задачах уровня «hello world», но на котором будет значительно тяжелее написать что-то большое и серьезное, - arc на jvm.

>В нем нет поддержки ооп и моп

ООП в нём используется в качестве «ассемблера». В 1.2 появились deftype, defprotocol и еще парочка ООП-фич. Насчёт моп - не всё же сразу. CLOS в CL тоже не сразу появился.

нет лучших возможностей для оптимизации кода

недавно появились transients. первая ласточка так сказать.

синтаксис менее униформен по сравнению с CL.

если не считать java-interop, не знаю где ты увидел неуниформность. скобок в нем меньше чем в CL, да и вербозности тоже.

Но опять-таки, все это может быть сделано в CL - синтаксический сахар делается с легкостью, а с многопоточностью посложнее, хотя и тут есть чем ответить - cl-stm - реализация stm модели, cl-muproc - реализация actor модели.

Нууу... какбы... двадцать лет уже делается, а всё никак не сделается.

На мой взгляд, на данный момент, clojure использует, я бы даже сказал паразитирует, на серьезных библиотеках из jvm и их объектной моделе, и подавляющее большинство программ - это обертки вокруг java libs. Я не видел еще ни одного достаточно серьезного проекта на этом языке (хотя бы 30-40к строк). Сейчас, его ниша - это маленький скриптовый недоязычок, который очень хорошо и элегантно выглядит на задачах уровня «hello world», но на котором будет значительно тяжелее написать что-то большое и серьезное, - arc на jvm.

Кложе 2 года только. Какие тут могут быть проекты на 40к строк. Тем более для лиспа (тем более - на базе JVM с таким количеством либ) я подозреваю что таких проектов вообще не предвидится в ближайшие несколько лет.

И если кложа - маленький скриптовый недоязычок, тогда какая ниша у CL?

надо Bradford Cross спросить сколько у них в flightcaster'е строк кода на кложуре

>недоумок

ничтожный недоумок

а я тебя знаю....

кстати, а SBCL работает под windows?

>Он просто позволяет немного быстрее интерпретировать некоторые отдельные инструкции JVM для работы со стеком. А это подойдет для любой стековой машины, включая даже Форт.

Вы кащениты откуда черпаете знания, поделитесь ? То что часть регистров arm отводится под стековую машину - да используй хоть в .NET. jazelle вообщето не для этого - оно предназначено для исполнения java-байткода jvm. Зарубите себе на носу. 140 байткодов поддерживаются напрямую аппаратно, 94 эмулируются arm-командами и остальные не поддерживаются.

А тебе баран пора уже последний в твоей жизни укол сделать.

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

Кроме как срать, ты же ничего не можешь идиот и ничего не знаешь а берешься судить. Кроме jazelle dbx который используется для jvm есть еще jazelle rct который используется в jit компиляторах. Как ты все это идиот будешь использовать в своих лиспах ? На java приложениях это дает ощутимый прирост скорости.

Кроме jazelle dbx который используется для jvm есть еще jazelle rct который используется в jit компиляторах. Как ты все это идиот будешь использовать в своих лиспах ?

http://www.arm.com/products/processors/technologies/jazelle.php?tab=Jazelle+Architecture

# Additionally Jazelle RCT can also be used to support execution environments beyond Java, such as Microsoft .NET Compact Framework, Python and others.

Хоть один нашелся кто хотя бы доки смотрит. rct я для примера привел о широких возможностях jazelle :) Оно просто использует расширения thumb и действительно может использоваться для оптимизации любого компилятора.

Оно просто использует расширения thumb и действительно может использоваться для оптимизации любого компилятора.

Thumb на Arm'е - это не расширение, это сужение какое-то. Кастрация опкодов, адресаций, иммедиэйтов ради размера инструкций со всеми вытекающими.

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

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

Как ты все это идиот будешь использовать в своих лиспах ?

На кой? Лисп, как и Си, прекрасно компилируется в нейтив.

Вот когда твоя Java с Jazelle на ARM заработает быстрее, чем Си на том же ARM, тогда и поговорим. А пока беги учить уроки, сявка.

На java приложениях это дает ощутимый прирост скорости.

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

> Лисп, как и Си, прекрасно компилируется в нейтив.

Да, и Java кстати тоже. Jazelle нужен только по той причине, что нет ресурсов на нормальный JIT, потому и используется программно-аппаратный недо-JIT.

>Кастрация опкодов, адресаций, иммедиэйтов ради размера инструкций со всеми вытекающими.

А разве не уменьшение размера динамических компиляторов являются целью оптимизации ? thumb повышает плотность кода всего-лишь, а в кортексах появилось для этого новое соятояние процессора thumbEE.

thumb повышает плотность кода в обмен на *сильно* обрезанные возможности. У arm'а они и так не охти.

>thumb повышает плотность кода в обмен на *сильно* обрезанные возможности. У arm'а они и так не охти.

Ты вообще отличаешь время компиляции от времени исполнения ? Думаю тебе нужно еще доки почитать. Состояние процессора у arm изменяется простым брэнчем.

Ты вообще отличаешь время компиляции от времени исполнения ?

При чём здесь оно?

отсутствие TCO, например, из больших

TCO ненужно, доказано Sun bugs.sun.com/view_bug.do?bug_id=4726340

“I might say yes to each of these but it is clear I must say no to all of them.” ―Guy Steele on language features Growing a Language, OOPLSA 1998

Хотя аналог Singularity с одной большой-пребольшой JVM наваять наверно можно

Уже http://www.jnode.org

зато несколько месяцев назад он писал про то, что tail call нужны для ОО-языков...

> ООП в нём используется в качестве «ассемблера»

Что это значит?

В 1.2 появились deftype, defprotocol и еще парочка ООП-фич

«Парочка фич» не сделают из него ООП. Пока хотя бы не появится наследования структур, об ООП говорить рано.

CLOS в CL тоже не сразу появился.

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

если не считать java-interop, не знаю где ты увидел неуниформность. скобок в нем меньше чем в CL, да и вербозности тоже.

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

Нууу... какбы... двадцать лет уже делается, а всё никак не сделается.

Нууу, не двадцать лет. По большому счету, подавляющее большинство библиотек было написано за последние 5-6 лет. Кроме того, autogensyming есть, autodestructuring делается на раз макросом, лямбда макрос #L() - есть, extensible sequences - апи было предложено и реализовано ажно в 2007 году кристофом родом, и т.д., все это есть в виде библиотек и работает.

Кложе 2 года только. Какие тут могут быть проекты на 40к строк. Тем более для лиспа (тем более - на базе JVM с таким количеством либ) я подозреваю что таких проектов вообще не предвидится в ближайшие несколько лет.

А как же написание компилятора кложи на самой кложе? Хотя там конечно поменьше будет, но хоть какой-то серьезный проект.

И если кложа - маленький скриптовый недоязычок, тогда какая ниша у CL?

Высокоуровневый универсальный язык программирования общего назначения :)

> надо Bradford Cross спросить сколько у них в flightcaster'е строк кода на кложуре

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

> А как же написание компилятора кложи на самой кложе? Хотя там конечно поменьше будет, но хоть какой-то серьезный проект.

Большая часть Closure написана на Java.

> Большая часть Closure написана на Java.

Так переписывают по-тихоньку :)

>Высокоуровневый универсальный язык программирования общего назначения :)

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

> Тормозной говно язык

Из динамических - один из самых быстрых.

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