Вся Java под GPL

>Да. А что?

Сами себе платите, сами для себя пишете и сами написаное используете?

>Если тебе злой дядя диктует выбор платформы - то ищи доброго дядю.

Мне их рынок диктует.

>Присматриваемся к Java kernel. Java SE 6 runtime типа 2 Мб, остальное по мере необходимости подкачивается из Инета.

че, и даже память сама заказывается в инете и потом тихо и незаметно в корпус влазит, ведя процессор 4-х ядерный на тонких ножках?! фигасе техника дошла!

> че, и даже память сама заказывается в инете и потом тихо и незаметно 
в корпус влазит, ведя процессор 4-х ядерный на тонких ножках?! фигасе 
техника дошла!

И это еще не все! Компьютеризация стала настолько масштабной, что 
теперь даже идиоты, вроде вас, могут свободно пользоваться интернетом. 
Это ли не прогресс!

// :(

>Понимаешь ли, жалкая безмозглая скотина, ниасилил именно ты. Ты, ублюдина быдлокодерящая, вообще не понял, о чём в статье речь. Ещё раз, медленно, для клинических русских дебильных плебеев: в статье нет сравнения систем комманд виртуальных машин. Сравниваются способы генерации кода во время выполнения. К обсуждаемой теме это никакого отношения вообще не имеет.

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

>Я тебе уже сказал, в чём фундаментальная разница между IL и JVM. Ты, говна кусок, не осилил? Убей себя тогда. Единственное вообще преимущество JVM над .NET - это class gc. Всё. Других преимуществ нет, одни недостатки.

А теперь пролетарский фанбой объяснит нам, вернее попробует объяснить, почему такая фееричная Mono сливает как Java http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&am... так и Scala http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=csharp&... по всем тестам? Может хвостовая рекурсия не помогает? Кстати, Виталий Святославович, перелогиньтесь. С vsl разговаривать удобнее, а цитаты сразу зеркалятся на башорг

>Явной же инструкции не добавят никогда.

И это правильно. Нечего из компьютерных систем делать по умолчанию дырявый дуршлаг, который может взломать любой китаец, сидя с ASUS EEE 701 у себя на горше за 3000 км. от сервера.

> Мне их рынок диктует.

Рынок вообще Windows диктует как основную целевую платформу. Что неплохо с .NET сочетается. Мне правда по фигу, я веб-сервисы пишу.

> А теперь пролетарский фанбой объяснит нам, вернее попробует объяснить, почему такая фееричная Mono сливает как Java http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&am...... так и Scala http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=csharp&;... по всем тестам? Может хвостовая рекурсия не помогает?

Т.е. у NET-а: "скорость и фичи" у M$.NET, а "кроссплатформенность" - у Mono? Оригинальное разделение... ;)

Объясните мне, как сломать через инструкцию tailcall?

Ну а про уровни верификации в .NET вы небось и сами знаете, хоть и являетесь дубиной.

> почему такая фееричная Mono сливает

А почему оно должно не сливать? Там performance далеко не первоочередной приоритет имеет у разработчиков, JIT ещё не отточен. Нужна производительность - есть родная реализация от Microsoft.

А LLVM по-прежнему рулит! И по фичам и по кроссплатформенности и по быстродействию. Не то, что ваши проприетарные недооткрытые быдлоподелия.

> А почему оно должно не сливать? Там performance далеко не первоочередной приоритет имеет у разработчиков, JIT ещё не отточен. Нужна производительность - есть родная реализация от Microsoft.

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

Приоритетная задача Mono - поддержка совместимости с MS. Как и в случае с GCJ и GNU Classpath шансы хотя бы приблизиться к исходной реализации равны нулю.

А учитывая тот факт, что у MS нет планов укреплять позиции любых ОС кроме Windows, остается только сожалеть о потраченных усилиях разработчиков Mono.

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

Да, JVM сливает .NET. В реализации от Microsoft. И JVM сливает даже тормозному Mono, если исполнять код, который без таких фичей эффективно работать не может (например, функциональные языки). По этой причине F# под .NET есть, а под JVM ничего подобного нет.

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

Правда, конечно же и .NET и JVM полный отстой с точки зрения разработчика компиляторов, с этим мало кто поспорит. Например, корректная и эффективная реализация continuations малореальна на любой из этих платформ. Так же, жесткого порицания достойна крайне низкая производительность исключений, которая на .NET и JVM одинаково тормозная и неудобная для практического применения.

LLVM всем хорош, кроме одного - это не взрослая платформа. Для LLVM ничего нет. Вот, например, хочу я веб-сервисы делать. С .NET я возьму всю готовенькую инфраструктуру и F#, с JVM обратно же всё готовенькое и например Kawa (или даже SISC). А что мне делать с LLVM? Клювом щёлкать?

>Рынок вообще Windows диктует как основную целевую платформу. Что неплохо с .NET сочетается.

На каком рынке? Офисного планктона? Подавляющая часть серверов как под *nix была, так и остается. А в виду того как ms двигает silverlight а adobe flex, то и планктону windows побоку в ближайшем будущем будет.

>Мне правда по фигу, я веб-сервисы пишу.

И оно конечно же крутится в продакшене под моно?

> А LLVM по-прежнему рулит! И по фичам и по кроссплатформенности и по быстродействию. Не то, что ваши проприетарные недооткрытые быдлоподелия.

Вобщето-то в Java остались не открытыми только ряд вспопогательных библиотек, поэтому она не менее открыта чем LLVM. А по поводу фич можно и поспорить - в LLVM например функция first class object и пожалуй это хорошо, но нет понятия объект и это пожалуй плохо.

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

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

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

> Для LLVM не только нет эффективного JIT, но и нет теоретической возможности его реализовать.

>> Для справки jruby, jython etc.

> Для справки, ты - кретин. Это говно неэффективно. Сравни тот же Jython с IronPython, хотя бы.

> Не о C# речь. И гуёвые быдлоприложения, вообще-то, идут на хер. Не для гуйни такие платформы нужны.

> Ты недоумок, реально. Под JVM невозможна эффективная реализация языков, отличных от Java.

>> Тебя про .net спросили. Причём тут mono? ;) Это, как бы, немножно не одно и то же.

> При том, что у них есть общее подмножество. Более чем достаточное. А гуйня, то есть, то, в чём они различаются, на хрен и не нужна.

> Тебе надо голову отрезать, жалкий ты недоумок. Ещё раз, медленно, для тупых: JVM годится только для Java. Точка. Все другие языки на JVM - грязные, неэффективные хаки.

> LLVM - регистровая трёхадрессная машина. Для корректной и эффективной генерации трёхадрессного кода нужны определённые спекуляции о свойствах конечной целевой машины, иначе же придётся восстанавливать AST (что непросто для трёхадрессного кода) и создавать его заново, уже зная о том, как устроенна целевая платформа.

> Теперь посмотри, придурок, в КАКОЙ байткод компилится jython и jruby. Понимаешь ли, убогий недоумок, байткод CLR - это совсем не то, что быдлобайткод JVM. В CLR есть явные value types, явный анбоксинг, явные хвостовые вызовы. В CLR можно делать методы неограниченного размера, что очень для оптимизаций полезно.

>> и если честно не понимаю что там такого принципиально нового

> Это от того, что ты - дебил. Сравни инструкции IL и JVM.

> И какое отношение твоя ссылка имеет к теме, а, придурь гнойная? Там нет сравнения систем инструкций в этих двух VM. Я тебе уже сказал, в чём фундаментальная разница между IL и JVM. Ты, говна кусок, не осилил? Убей себя тогда. Единственное вообще преимущество JVM над .NET - это class gc. Всё. Других преимуществ нет, одни недостатки.

>> Для Java - Kawa, ABCL есть

> К нормальным их отнести нельзя. Kawa крива, ABCL не шустр вовсе.

>> Хотя для .Net есть F#,

> И Nemerle. Вообще, тут список жирненький: http://dotnetpowered.com/languages.aspx

>> Объясни мне, родной, что я теряю без явного анбоксинга и явных value types.

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

>> P.S. Про хвостовую рекурсию согласен, но еще не вечер, грядет Java 7

> Не будет её в Java7. Максимум, что могут сделать, это неявное, автоматическое распознавание НЕКОТОРЫХ хвостовых вызовов (а это и так есть в JRE от IBM, толку от этого никакого). Явной же инструкции не добавят никогда.

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

> Bigloo - но это только с кросскомпиляцией. Всем хорош. MBase - не open source, документация никакая, но шустрый и много интересных фичей. Под mono работает все, что я пробовал. В реальных задачах применяю F# и Nemerle.

>> Nemerle - это тоже что-то типа окамла?

> Не совсем. Там есть частичный type inference, но, естественно, с поправкой на полиморфизм системы типов .NET. Главная же фича в Nemerle - это метапрограммирование на макрах, почти такое же мощное, как в Common Lisp.

> mono давно уже взрослая и самостоятельная платформа. Так что я предпочитаю рассматривать M$ .NET как альтернативную реализацию Mono, а не наоборот. Если разрабатывать под Mono целенаправленно, то никаких проблем не будет.

>> Так все разработки МС сначала делаются на дотнете

> Меня абсолютно не волную чьи либо чужие разработки. Я выбираю платформу, под которую разрабатывать мне, и мой выбор от мнения M$ и прочих никак зависеть не может. Mono предоставляет всё, что мне нужно, тогда как JVM - нет, следовательно, под Mono и разрабатываю, а .NET под альтернативной ОС - это просто ещё одна платформа, на которой мои приложения на халяву могут работать. Перестанут работать - мне обратно же наплевать, Mono он и под альтернативную ОС имеется, представьте себе.

> Понимаешь ли, жалкая безмозглая скотина, ниасилил именно ты. Ты, ублюдина быдлокодерящая, вообще не понял, о чём в статье речь. Ещё раз, медленно, для клинических русских дебильных плебеев: в статье нет сравнения систем комманд виртуальных машин. Сравниваются способы генерации кода во время выполнения. К обсуждаемой теме это никакого отношения вообще не имеет. А теперь убей себя, безмозглый пролетарский выпердыш.

> Короче, мразёныш, ты слил. Ни хрена по делу сказануть не смог, и полез выпендриваться. Так вот, сука, запомни: IL гораздо более гибкая машина, чем JVM. И у тебя не хватило ни мозгов ни знаний чтобы это утверждение опровергнуть, мне же было достаточно перечислить несколько фичей, которые это убедительнейшим образом доказывают. Можешь убить себя. Ты не нужен, жалкий быдлокодерёныш.

Луговский, ты?! :)

> но нет понятия объект и это пожалуй плохо.

Чем плохо?!? Объекты можно реализовать на более высоком уровне, а вот first class functions - хрен.

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

Вот! Наконец то подходим к главному выводу о том, кто же рулит на самом деле.

А рулит, представьте себе, Форт. Поскольку он является виртуальной машиной с ОТКРЫТЫМ набором инструкций. Так-то!

Это какие-то два или три других мудака.

> Да, JVM сливает .NET. В реализации от Microsoft. И JVM сливает даже тормозному Mono, если исполнять код, который без таких фичей эффективно работать не может (например, функциональные языки).

Это не более чем общие фразы. Если хотите подтвержить свои утверждения просто напишите что-нибудь на F#, я попробую написать на том же Scala и сравним производительность скажем на 1'000'000 итераций.

> По этой причине F# под .NET есть, а под JVM ничего подобного нет.

Оригинально - для JVM нет ничего подобного F#, но Scala не считать :-)

> И не надо про Scala, там те немногие примеры, которые в тестах используют рекурсию, настолько примитивны что компилятор просто раскрывает эту рекурсию в цикл.

А есть ли разница с точки зрения практики, когда происходит преобразование рекурсии в цикл - в AOT или JIT?

> А рулит, представьте себе, Форт. Поскольку он является виртуальной машиной с ОТКРЫТЫМ набором инструкций. Так-то!

Вывод правильный, но не единственный. Кроме Форта есть еще скажем Лисп, да и наверное много чего есть.

> Кроме Форта есть еще скажем Лисп, да и наверное много чего есть

Лисп - это не VM, это язык. А Форт - это не язык, это расширяемая стековая VM. Так понятнее?

> Это не более чем общие фразы.

Да там же, на том же шутауте всё есть.

> Оригинально - для JVM нет ничего подобного F#, но Scala не считать :-)

Scala не является чем либо подобным F#. Если писать на Scala в сильно функциональном стиле, то чушь получится.

> А есть ли разница с точки зрения практики, когда происходит преобразование рекурсии в цикл - в AOT или JIT?

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

Например, (define (f1 f2 p1 x) (if (p1 x) (f2 f1 p1 x) x))

Попробуй, придумай схему компиляции этой функции без поддержки хвостовых вызовов на низком уровне.

> Лисп - это не VM, это язык. А Форт - это не язык, это расширяемая стековая VM. Так понятнее?

S-выражение Lisp == слово Форт, подробнее см. http://www.lisp.org/table/syntax.htm

Так понятнее?

> S-выражение Lisp == слово Форт

Ты бредишь. Сильно так бредишь.

Форт - стековая виртуальная машина, при реализации на шитом коде одно слово = один токен (то есть, одна инструкция VM). Лисп же на виртуальную машину не тянет, это сильно более высокий уровень.

Ты бы ещё Си назвал виртуальной машиной.

P.S. И попрошу не смешивать промежуточное представление с виртуальной машиной. Иногда их области применения пересекаются, но они являются совершенно разными сущностями. Виртуальная машина допускает самостоятельное выполнение, в отличии от. А так - да, и Си, и Лисп, и C--, и даже, прости меня боженька, Java - все могут служить в роли промежуточного представления при компиляции из языка более высокого уровня.

> Не каждую хвостовую рекурсию можно развернуть в цикл во время компиляции. Только самые примитивные её формы, когда функция вызывает саму себя. Если же это цепочка функций, включая и неизвестные заранее во время компиляции, то тут без поддержки со стороны VM ничего не сделаешь.

> Например, (define (f1 f2 p1 x) (if (p1 x) (f2 f1 p1 x) x))

> Попробуй, придумай схему компиляции этой функции без поддержки хвостовых вызовов на низком уровне.

Для начала бы неплохо понять что эта волшебная функция делает.
Могу допустить, что в f1 передается некая функция f2, предикат p1 и скажем целое x.
Если предикат срабатывает для данного х, то вызывается f2, в которую передается f1. Достаточно бесхитростный компилятор C сгенерирует следующее

push [sp-3]
call p1
jz return
pop ax, bx, cx
push cx, bx, &f1, ax
jmp f2
return:
ax = [sp-3]
ret 5

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

> Для начала бы неплохо понять что эта волшебная функция делает.

А что тут непонятного? Это банальная Схема (ну да ты понял в общем-то правильно).

> компилятор C сгенерирует следующее

Именно что jmp. А в JVM такое хрен сделаешь.

> Следствие из этого - затраты virtual call.

Мне не жалко. Пусть будет вызов виртуального метода, но ХВОСТОВОЙ. Чтоб стек не расходовался.

Проблема то не в производительсности, а вообще в самой принципиальной возможности реализации такого типа алгоритмов.

> Форт - стековая виртуальная машина, при реализации на шитом коде одно слово = один токен (то есть, одна инструкция VM). Лисп же на виртуальную машину не тянет, это сильно более высокий уровень.

Я хренею с этих русских! В простейшем лисп коде каждый элемент либо ссылка на символ, либо ссылка на литерал. Так вот каждый символ и есть аналог слова форт.

> в ней нет функций - есть только методы

Кстати, в .NET тоже тут не всё гладко, для того, чтоб код был верифицируемым, надо использовать как минимум делегаты. Просто так указатель на функцию можно передавать только в unsafe коде. Ну да хороша хотя бы сама принципиальная возможность переключиться в unsafe, у JVM и того нет.

> P.S. И попрошу не смешивать промежуточное представление с виртуальной машиной. Иногда их области применения пересекаются, но они являются совершенно разными сущностями. Виртуальная машина допускает самостоятельное выполнение, в отличии от. А так - да, и Си, и Лисп, и C--, и даже, прости меня боженька, Java - все могут служить в роли промежуточного представления при компиляции из языка более высокого уровня.

Именно промежуточное представление не может себя выполнять!

> В простейшем лисп коде каждый элемент либо ссылка на символ, либо ссылка на литерал

И как ты этот код исполнять будешь, дурень? Шитый код исполняется процессором, напрямую. Лиспу же нужна ещё и специфицированная операционная семантика.

> Так вот каждый символ и есть аналог слова форт.

Нет, дурень. Не есть ни разу.

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

> Именно промежуточное представление не может себя выполнять!

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

> Мне не жалко. Пусть будет вызов виртуального метода, но ХВОСТОВОЙ. Чтоб стек не расходовался.

> Проблема то не в производительсности, а вообще в самой принципиальной возможности реализации такого типа алгоритмов.

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

В то время как нигде в спецификации jvm не сказано, что

void f() { g(); }

должно приводить к реальному коду после JIT

f: call g ret

а не к

f: jmp g

>> В простейшем лисп коде каждый элемент либо ссылка на символ, либо ссылка на литерал

> И как ты этот код исполнять будешь, дурень? Шитый код исполняется процессором, напрямую.

Никогда не исполняется напрямую! В одном случае есть рудиментальный интерпретатор, который исполняет f1 f2 и т.д.

, а другом тупо call f1 call f2 и т.д.

> Лиспу же нужна ещё и специфицированная операционная семантика.

делается теми же средствами, что и у Форта

> Так вот каждый символ и есть аналог слова форт. > Нет, дурень. Не есть ни разу.

> То есть, конечно ты можешь преобразовать список (1 2 . 3), например, > в код 1 2 3 CONS CONS, но это будет только генерация структуры > данных, преобразование же семантики будет существенно сложнее.

(2 . 3) дает (CONS 2 3) по определению! а точка не более чем удобный способ записи вызова

> Java не может, потому что без инструкции хвостовой рекурсии нельзя

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

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

Как я уже говорил, сейчас есть JVM, которые компилируют такой код (не всегда, правда, только в примитивных случаях) корректно. Тот же IBM JRE, например. Но! Я не могу просто взять и опубликовать jar, использующий рекурсию - поскольку знаю, что до хера JVM, которые сработают некорректно. Нельзя это рассматривать как оптимизацию, такое отношение сразу все возможности начисто закрывает.

> а другом тупо call f1 call f2 и т.д.

И что? Это всё равно может рассматриваться как байткоды VM.

> делается теми же средствами, что и у Форта

Какими же? Ты, похоже, Лиспа не понимаешь совсем. Лисп сложен, на порядок сложнее Форта. У Лиспа есть переменные, есть замыкания. Ему требуется сложный компилятор или интерпретатор. Тогда как Форту ни хрена не надо, его можно однозначно транслировать в машинный код.

> (2 . 3) дает (CONS 2 3) по определению!

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

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

> Потому, что я должен иметь возможность контроллировать - попадёт этот вызов в стек или нет. Никакая VM не может этого за меня решить - хочу ли я видеть вызов в stack trace при исключении, или его надо преобразовать в переход, да ещё и при этом стек почистить небезопасным быстрым slice-ом. Это первое.

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

> Как я уже говорил, сейчас есть JVM, которые компилируют такой код (не всегда, правда, только в примитивных случаях) корректно. Тот же IBM JRE, например. Но! Я не могу просто взять и опубликовать jar, использующий рекурсию - поскольку знаю, что до хера JVM, которые сработают некорректно. Нельзя это рассматривать как оптимизацию, такое отношение сразу все возможности начисто закрывает.

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

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

Как говорится "время нас рассудит".

> Судя по всему Лисперы просто в шоке от того, что у них нет инструкции хвостовая рекурсия.

А в Лиспах обычно и нет возможности проинспектировать стек, да и исключений нет. А в современных VM это есть. И эту возможность не хочется терять тоже. Так что нужен контроль.

И, да, кстати, любые лиспы кроме Схемы не гарантируют корректность хвостовых вызовов, и потому рекурсивные алгоритмы в них не применяются так активно.

> а NET наоборот привествует активные подсказки в виде using, явной хвостовой рекурсии и т.п.

Зато сама виртуальная машина в .NET проще и более высокоуровневая. Она не допускает никаких операций над стеком, вообще. Так что это ещё вопрос, где больше на JIT перекладывается.

>Как я уже говорил, сейчас есть JVM, которые компилируют такой код (не всегда, правда, только в примитивных случаях) корректно. Тот же IBM JRE, например. Но! Я не могу просто взять и опубликовать jar, использующий рекурсию - поскольку знаю, что до хера JVM, которые сработают некорректно. Нельзя это рассматривать как оптимизацию, такое отношение сразу все возможности начисто закрывает.


П*здобол, строишь из себя умного, а такие ляпы допускаешь - вот тебе на закуску Scala:

def f(i: int): unit =
{
if (i<10)
{
Console.println(i);
f(i+1);
}
};


Простейшая и банальнейшая рекурсия, а вот что выдает javap:


public void f(int);
Code:
0: aload_0
1: astore_2
2: iload_1
3: ldc #31; //int 10
5: if_icmpge 25
8: getstatic #36; //Field scala/Console$.MODULE$:Lscala/Console$;
11: iload_1
12: invokestatic #42; //Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
15: invokevirtual #46; //Method scala/Console$.println:(Ljava/lang/Object;)V
18: iload_1
19: iconst_1
20: iadd
21: istore_1
22: goto 2
25: return


Хотелось бы услышать твой комментарий к строке 22, и особенно пояснение в чем будет состоять отличие выполнения этого бкода на SUN JVM и IBM JVM.


P.S. Мне как прикладному программисту глубоко насрать кто будет поддерживать оптимизацию хвостовой рекурсии JVM или компилятор.

>> а другом тупо call f1 call f2 и т.д.
> И что? Это всё равно может рассматриваться как байткоды VM.
то, что на LISP я могу сделать тоже самое

>> делается теми же средствами, что и у Форта
> Какими же? Ты, похоже, Лиспа не понимаешь совсем. Лисп сложен, на порядок сложнее Форта.

> У Лиспа есть переменные,
переменная - ссылка на объект в памяти

> есть замыкания.
замыкание - не более чем анонимная функция, которая опять же использует ссылки на объекты памяти

> Ему требуется сложный компилятор или интерпретатор. Тогда как Форту ни хрена не надо,

кроме словаря, так Лисп без словаря тоже как бы не живет

> его можно однозначно транслировать в машинный код.

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

> > (2 . 3) дает (CONS 2 3) по определению!

> Именно это у меня и записано, болван. Форт, если ты не в курсе, постфиксную нотацию использует.

попридержи язык! у тебя написано, что можно построить структуру, но это будет лишь структура
я же говорю тебе, что (2 . 3) порождает исполняемое выражение, результат которого есть пара, в понятном для тебя смысле - это
call put 2
call put 3
call cons

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

Т.е. предлагаешь defun, let и прочее переписать на Форт? Сложная и самое главное тупая задача, потому лисп легко обрабатывает сам себя и вводит новые сущности, а когда пытаешься их продублировать в другой среде - получаешь проблемы.

> А в Лиспах обычно и нет возможности проинспектировать стек, да и исключений нет. А в современных VM это есть. И эту возможность не хочется терять тоже. Так что нужен контроль.

> И, да, кстати, любые лиспы кроме Схемы не гарантируют корректность хвостовых вызовов, и потому рекурсивные алгоритмы в них не применяются так активно.

и шо вы говорите

бред. Я тестировал, на моей задаче jit обгонял "gcc -O3".

А шо, кто-то еще гарантирует? Я могу от любой реализации Common Lisp ждать корректной хвостатости?

> вот тебе на закуску Scala:

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

> оптимизацию хвостовой рекурсии

Да... Ты тупой. ЭТО НЕ ОПТИМИЗАЦИЯ!!!

> бред. Я тестировал, на моей задаче jit обгонял "gcc -O3".

То есть одна и та же программа, скомпиленная на llvm и интерпретированная lli была быстрее, чем скомпиленная gcc? Попробуй проверить lli vs llc. А лучше дай задачу. Сам поэкспериментирую.

> то, что на LISP я могу сделать тоже самое

Как?!?

> переменная - ссылка на объект в памяти

Ты бредишь, болезный.

> замыкание - не более чем анонимная функция, которая опять же использует ссылки на объекты памяти

Как ты замыкания реализовать собираешься на низком уровне? Ведь ты претендуешь на то, что лисп - низкоуровневая виртуальная машина, не так ли?

> про однозначную трансляцию в машинный код я не говорил,

Мы тут VM выбираем, а ты, веталег, со своим лиспом встрял, как всегда неуместно.

> я же говорю тебе, что (2 . 3) порождает исполняемое выражение

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

> Т.е. предлагаешь defun, let и прочее переписать на Форт?

Нет. Я предлагаю написать компилятор высокоуровневого языка Лисп в низкоуровневую стековую виртуальную машину, которой является Форт. Не нравится Форт - возьми JVM.

> Сложная и самое главное тупая задача

В ней нет ничего сложного, вообще.

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

Что за бред ты несёшь? Что значит "обрабатывает сам себя"? Лисп выполняется какой-то реальной или виртуальной машиной. Интерпретаторы не рассматриваем вообще, ибо глупо, а компилировать Лисп в плоский код надо даже на Лисп-машинах.

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

Ты п*здабол за свои слова то ответь! Чем будет отличаться исполнение этого байт кода в разных JVM?

P.S. А на то что тебе надо, мне посрать!

> Ты п*здабол за свои слова то ответь! Чем будет отличаться исполнение этого байт кода в разных JVM?

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

Но этого мало для реализации функциональных языков. Нужно, чтобы ЛЮБОЙ хвостовой вызов не отжирал зря место в стеке вызовов, а не только вызов функцией себя самой. Пример функции, которая должна делать хвостовой вызов функции, неизвестной во время компиляции, приведён выше. Попробуй задуматься о том, как этот код будет скомпилирован в JVM.

Программисты vs. идиоты - матершинники, мля.

По твоему, существо, не видящее разницы между хвостовым вызовом, когда функция вызывает саму себя, и когда функция вызывает другую функцию, может называться программистом?

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