LINUX.ORG.RU

Вся Java под GPL

 , , ,


0

0

Открытие исходников Java Platform, Standard Edition (SE) началось ещё в 2006 году. Но некоторые библиотеки шифрования, графические библиотеки, звуковой движок и некоторая часть кода, отвечающая за управление SNMP, все ещё не открыты в соответствии с GNU General Public License.

Все эти компоненты составляют около 4% исходников, но эта мелочь препятствует включению OpenJDK в стандартные дистрибутивы.

Sun Microsystems собирается лицензировать под лицензией GNU GPL все без исключения компоненты Java, чтобы она считалась полностью открытой платформой, а набор OpenJDK смог свободно распространяться и быть включенным в дистрибутивы Linux как полноценная платформа Java.

>>> Подробности

Ответ на: комментарий от DOKA

> И в чем проявляется это отставание?

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

> а .NET полноценно только на Windows?

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

anonymous
()
Ответ на: комментарий от anonymous

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

примеры прог хотя бы уровня азуреуса юзающих точкаНет и написанных не на С за решёткой

anonymous
()
Ответ на: комментарий от anonymous

>а JVM - только для очень убогого язычка для тупых индусов.

ты чё в заморозке последние 5 лет пролежал? под JVM уже 5 (не считая самой Java) языков и количество с каждым годом растёт. вот зачем нужен .NET - вот это полная загадка. кросплатформенность между виндой и чем? зачем тогда вся ета ерунда? пишите прямо на C++

gigabito
()
Ответ на: комментарий от anonymous

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

4.2 whitespace не поддерживает!

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

anonymous
()
Ответ на: комментарий от anonymous

>Mono много где полноценно работает.

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

Deleted
()
Ответ на: комментарий от anonymous

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

Из юзабельных Scala еще, ну а так вообще еще куча всяких, разной степени паршивости.

anonymous
()
Ответ на: комментарий от anonymous

>на cpp индусам сложно писать вот мелкософт и старается

ну так сделали бы компилятор с С# и не выёживались

gigabito
()
Ответ на: комментарий от anonymous

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

Опять ложь. Садитесь, двойка.

DOKA
()
Ответ на: комментарий от anonymous

>Mono много где полноценно работает. А гуйня никого не интересует, кроме самых быдловатых.

Список "много где", пожалуйста.

jackill ★★★★★
()
Ответ на: комментарий от gigabito

> Кроссплатформенность между виндой и чем?

Как чем? Ну ты даешь! Майкрософту надо же совместимость предложений между той же хр и вистой обеспечивать ;)

temy4
()
Ответ на: комментарий от temy4

Тьфу, блин!

:s/предложений/приложений/

пора видимо спать идти

temy4
()
Ответ на: комментарий от anonymous

> 4.2 whitespace не поддерживает!
> Для справки jruby, jython etc.

вот только ненадо @#$ с пальцем сравнивать.
VB.NET, J# не интерпретируются с помощью C#. нет никакой каловой прослойки как у jruby, jython в виде жабы.
можно и на бейсике эмулятор ассемблера написать, но это идиотизм полнейший.

anonymous
()
Ответ на: комментарий от jackill

Насколько знаю mono в gnome-овских app конкретно юзается. Но это mono и .NET действительно не одно и тоже. Некорректно сравнивать .NET+mono и Java. Сам лично долгое время писал на .Net но бросил этого громоздкого навороченного слона, по большому счету из-за ASP.NET помоему большой костыль, неудачная идея перенести идею форм на Web. А ява так вообще тормоза по моему у нее это фича и не надо спорить я знаю о чем говорю, когда запускается LWCL это можно пообедать сходить и в память садится процессами по 500мб этож ваще ... тут кстати об azureus говорили, прикольная прога но страдает тормознутостью и громоздка в памяти. О тонкостях языка Java говорить не буду, но наслышан и могу услышанное сравнить с C#. Как язык Java не тянет на C#. Вывод из всего сказанного, что я не на C# и не на Java, а если бы мелкософт сделал бы реальную кросcплатформенность (моно не в счет), Java давно бы на задворках оказался. И вообще M$ это зло

anonymous
()
Ответ на: комментарий от anonymous

> Как язык Java не тянет на C#.

Как язык C# не тянет на Java.

Что за поток сознания написал анонимус? Тролль-кащенит, что ли?

Bioreactor ★★★★★
()
Ответ на: комментарий от anonymous

>вот только ненадо @#$ с пальцем сравнивать.
VB.NET, J# не интерпретируются с помощью C#. нет никакой каловой прослойки как у jruby, jython в виде жабы.
можно и на бейсике эмулятор ассемблера написать, но это идиотизм полнейший.


О, ламерье понабежало!
Для справки:
1. Собственно Java - компилится в бкод (как это не удивительно)
2. Groovy - компилится в байт код
3. Scala - компилится в бкод
4. JavaFX - компилится в бкод
5. JRuby - комилится в бкод
6. Jython - не знаю

По поводу поддержки динамических языков на уровне JVM смотрим на да винчи.

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

P.S. Достали блин анаизмусы купившие книжку по C#. Сам изучаю .NET щас, и если честно не понимаю что там такого принципиально нового. Хотя конечно маркетоиды у негрософта поработали на 5+.

anonymous
()
Ответ на: комментарий от arum

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

anonymous
()
Ответ на: комментарий от anonymous

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

4.2

>> а .NET полноценно только на Windows? > Mono много где полноценно работает. А гуйня никого не интересует, кроме самых быдловатых.

На каких платформах кроме Windows можно запустить приложеине под .Net 3.5 (кстати уже не самый свежий) ???

VoDA ★★
()
Ответ на: комментарий от anonymous

А что ты хотел? Это ЛОР: нельзя понять, что вообще всем обитателям по душе. А те кто понял - уже не с нами, а в специально отведенных для таких случаев местах

temy4
()
Ответ на: комментарий от anonymous

> > И в чем проявляется это отставание?

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

тупые индусы - это те, кто не видит принципиальной разницы между языком скриптования sed, питоном и C#. Это те, для которых является несомненным преимуществом возможность использовать "любой" язык для решения "любых" задач: sed для создания интерактивного интерфейса приложения, php для написания ядра ОС, perl для 3D-игр, C# для драйверов видеокарт

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

> примеры прог хотя бы уровня азуреуса юзающих точкаНет и написанных не на С за решёткой

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

anonymous
()
Ответ на: комментарий от gigabito

> под JVM уже 5 (не считая самой Java) языков и количество с каждым годом растёт.

Ты недоумок, реально.

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

anonymous
()
Ответ на: комментарий от Deleted

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

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

anonymous
()
Ответ на: комментарий от DOKA

> Опять ложь. Садитесь, двойка.

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

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

anonymous
()
Ответ на: комментарий от anonymous

> О, ламерье понабежало!

Ну да, ты например.

Теперь посмотри, придурок, в КАКОЙ байткод компилится jython и jruby.

> если он потом все равно собирается в бкод JVM/CLR

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

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

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

anonymous
()
Ответ на: комментарий от VoDA

А кому нужен 3.5, недоумок? 3.5 = 2.0 + ненужные библиотеки.

anonymous
()
Ответ на: комментарий от Neksys

Шитый код - это хорошо, Форт - это реально универсальная VM, но, пардон, с хорошим JIT это сравнивать нельзя. Другая у него ниша.

anonymous
()
Ответ на: комментарий от anonymous

И какое отношение твоя ссылка имеет к теме, а, придурь гнойная? Там нет сравнения систем инструкций в этих двух VM.

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

anonymous
()
Ответ на: комментарий от anonymous

А есть ли нормальные реализации LISP (желательно COMМON LISP) для .Net? Для Java - Kawa, ABCL есть. Хотя для .Net есть F#, а для жабки что-то подобное только в зачаточном состоянии.

cab ★★★★
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

А какой-то из лиспов под .Net вы юзали? В наиболее известном L# - насколько мне известно, отсутствует lambda. Nemerle - это тоже что-то типа окамла?

cab ★★★★
()
Ответ на: комментарий от cab

>А какой-то из лиспов под .Net вы юзали? В наиболее известном L# - насколько мне известно, отсутствует lambda. Nemerle - это тоже что-то типа окамла?

Забыл добавить. Какой из них наиболее юзабелен под моно?

cab ★★★★
()
Ответ на: комментарий от anonymous

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

Я вижу еще одно преимущество - щас я допишу 3-х звенную софтину с гуей, запскаемую через JWS из JBoss'а под linux, а потом перетащу все под винды и там тоже все будет работать (как ни странно). А потом я получу денюшку, а ты, друг ононимус, можешь и дальше дрочить, показывая какой-ты умный.

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от cab

Bigloo - но это только с кросскомпиляцией. Всем хорош.

MBase - не open source, документация никакая, но шустрый и много интересных фичей.

Под mono работает все, что я пробовал. В реальных задачах применяю F# и Nemerle.

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

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

anonymous
()
Ответ на: комментарий от anonymous

Завтра тут будете? Если нет, то можно списаться - mksendings(гав)ua.fm - - еще пораспрашивать хочу.

cab ★★★★
()
Ответ на: комментарий от anonymous

Все то вы говорите может и правильно, но вот какие есть два момента:

1. На платформах, отличных от виндовс, нормальной реализации дотнета нет, моно постоянно в роли догоняющего.

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

Так что вот.

anonymous
()
Ответ на: комментарий от anonymous

> 1. На платформах, отличных от виндовс, нормальной реализации дотнета нет, моно постоянно в роли догоняющего.

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

anonymous
()
Ответ на: комментарий от anonymous

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

Так все разработки МС сначала делаются на дотнете, а потом уже когда-нибудь, возможно доберуться и до моно.

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

>И какое отношение твоя ссылка имеет к теме, а, придурь гнойная? Там нет сравнения систем инструкций в этих двух VM.

Английский не осилил. Тебе сюда http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0%D0%BB...

Береги ж@#у.

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

Жаба не нужна, о чем спор-то?

anonymous
()
Ответ на: комментарий от anonymous

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

Зарплату вы тоже себе сами платите?

anonymous
()
Ответ на: комментарий от anonymous

Задолбали недоновости постить. SUN уже сто лет собирается что-то открыть до конца и всё никак не может. Когда откроют тогда и посмотрим.

anonymous
()
Ответ на: комментарий от anonymous

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

Можешь убить себя. Ты не нужен, жалкий быдлокодерёныш.

anonymous
()
Ответ на: комментарий от anonymous

MSIL - проприетарное говно. JVM - проприетарное говно. LLVM - наше ВСЁ!

anonymous
()
Ответ на: комментарий от anonymous

>Да. А что?

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

>Я тебе уже сказал, в чём фундаментальная разница между 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 км. от сервера.

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

> А теперь пролетарский фанбой объяснит нам, вернее попробует объяснить, почему такая фееричная 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? Оригинальное разделение... ;)

yyk ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

> 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. И у тебя не хватило ни мозгов ни знаний чтобы это утверждение опровергнуть, мне же было достаточно перечислить несколько фичей, которые это убедительнейшим образом доказывают. Можешь убить себя. Ты не нужен, жалкий быдлокодерёныш.

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

pitekantrop ★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

anonymous
()
Ответ на: комментарий от pitekantrop

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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





anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

void f() { g(); }

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

f: call g ret

а не к

f: jmp g

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

>Как я уже говорил, сейчас есть 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 или компилятор.

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Как?!?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

>Шитый код - это хорошо, Форт - это реально универсальная VM, но, пардон, с хорошим JIT это сравнивать нельзя.

в Tamarin (компилятор JavaScript в Firefox 3, Flash9) есть VM и JIT. На Форте.

>Другая у него ниша.

Это да.

anonymous
()
Ответ на: комментарий от anonymous

> корректная и эффективная реализация continuations малореальна на любой из этих платформ.

а мужыки-то не знают... http://www.seaside.st/community/development/seaside4j .. или continuations framework на смоллтоке уже не труЪ? где тут у нас самая эффективная реализация?

и вообще, google "Java continuations" выдает 10 800 ссылок, ".NET continuations" выдаёт 62.

О чём это говорит? Да ниачом. Про эффективность -- ХЗ. continuations реализуются на любом языке, хоть на бейсике или си с longjmp (если позаботиться о контексте руками). Интуитивно понятно, что лучший язык для continuations -- это шитый код или Algol-58 где в IF только GOTO было, только GOTO на GOSUB заменить :)) или трехадресный байткод с предикатами, ага. Типа cond :ifTrue [B1] :ifFalse [B2]. Или вообще на ассемблере с RET (а адрес выхода на стеке руками править, да).

anonymous
()
Ответ на: комментарий от anonymous

>А в Лиспах обычно и нет возможности проинспектировать стек,

это когда бектрейс в SLIME вываливается с символами? странно, а я и не заметил, что его нету

>да и исключений нет

зато conditions есть

anonymous
()
Ответ на: комментарий от anonymous

>О тонкостях языка Java говорить не буду,

Ты ж не Луговский

>Как язык Java не тянет на C#.

Потому что создан был в эпоху 100МГц процессоров и Лексикона и FoxPro для DOS. А счас в мобилах 200МГц.

>...а если бы мелкософт сделал бы реальную кросcплатформенность (моно не в счет), Java давно бы на задворках оказался.

Если БЫ Microsoft БЫ сделал БЫ .NET кроссплатформенным в 2001 году, когда выпустил его, то в 2002 году о нем бы уже никто не помнил, не было в 2002 году такой фирмы- Microsoft, она БЫ разорилась БЫ, и .NET 2.0 уже не увидел БЫ свет. Mono это не .NET, это еще одна приманка переманить индусских быдлокодеров с Linux в Windows

>то что написал ананимус выше, это бред >arum (*) (29.04.2008 9:42:52)

+500

Интересно, этому анонимусу хотя бы 20 лет исполнилось? Если да, то как он до сих пор не упал с 20 этажа и не попал под поезд, и не убился током, при том, насколько неадекватно он воспринимает окружающую действительность? Ведь такие тупые обычно заканчивают свой путь премией Дарвина.

anonymous
()
Ответ на: комментарий от anonymous

>Сам изучаю .NET щас, и если честно не понимаю что там такого принципиально нового. Хотя конечно маркетоиды у негрософта поработали на 5+.

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

anonymous
()
Ответ на: комментарий от anonymous

> и городить свой вариант чужой разработки

Ложь. Ты сходи, посмотри, сколько инновационных публикаций предшествовало .NET, сколько диссертаций на основе этой разработки защищено. Они реально много нового в теорию виртуальных машин внесли.

anonymous
()
Ответ на: комментарий от anonymous

> А счас в мобилах 200МГц.

Будешь смеяйца, но C# тоже в тех же мобилах ничуть не хуже себя чувствует. Есть ведь .NET Compact Framework, если ты не знал.

> она БЫ разорилась БЫ

За что люблю ЛОР - тут до фига великих аналитиков и экономистов. Жаль только, что все они такие безграмотные.

> Mono это не .NET

Сколько не говори "халва", а во рту слаще не станет. Mono это .NET, как бы тебе не хотелось обратного.

anonymous
()
Ответ на: комментарий от anonymous

> а мужыки-то не знают...

Сказано же - "эффективная". А это - трамплины тормозные.

anonymous
()
Ответ на: комментарий от anonymous

>инновационных публикаций

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

anonymous
()
Ответ на: комментарий от anonymous

>Mono это .NET, как бы тебе не хотелось обратного.

я пишу исключительно кроссплатформенный софт. венда — платформа? линух — платформа? Haiku, макось, FreeDOS… и все они работают на x86. следовательно, любая моя программа, которая запускается на x86 — кросплатформенна, вне зависимости от того, какой API она использует.

если это не так, тогда мона не является вротнетом — точно так же, как венда не является линуксом, хотя обе работают на x86.

anonymous
()
Ответ на: комментарий от anonymous

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

Как я понимаю, ты - тупая шпана, чьё представление о Computer Science ограничивается знанием о том, что где-то на полке у друга Васи стоит трёхтомник Кнута? Тогда с тобой, ничтожеством, и спорить не о чем. Если бы ты не был мразью и не был бы тупицей, то ты бы читал статьи от авторов из Microsoft Research, это неизбежно. Слишком многие из лучших на данных момент специалистов работают именно там. И многое из их результатов вошло в .NET. Ну да тебе, плебею из убогой, технологически отсталой страны третьего мира, таких вещей знать и не полагается.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Ещё раз, ублюдок: там занимаются настоящей наукой. Тебе такие имена, как Лука Карделли и Робин Милнер что либо говорят, или ты совсем неграмотная тупая скотина?

Ты, жалкий тупой выродок, имеешь хотя бы минимальное представление о Computer Science, а, мразь,

anonymous
()
Ответ на: комментарий от anonymous

Опровергать бессвязный бред? На кой. Ты - мразь. Ты - тупица. Зачем твой поток сознания, не содержащий осмысленной информации, пытаться опровергать? Тебя просто надо удавить, и всё. Спорить с мразью смысла никакого нет.

anonymous
()
Ответ на: комментарий от anonymous

хуёвый из тебя vsl. Виталик умный был, а ты унылый дурак.

anonymous
()
Ответ на: комментарий от anonymous

> Ты, жалкий тупой выродок, имеешь хотя бы минимальное представление о Computer Science, а, мразь,

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

// :(

anonymous
()
Ответ на: комментарий от anonymous

А у меня серьёзные сомнения, что человек, не являющийся мразью, может сказать "там занимаются фигурной дрочкой за деньги".

anonymous
()
Ответ на: комментарий от anonymous

> А у меня серьёзные сомнения, что человек, не являющийся мразью, может сказать "там занимаются фигурной дрочкой за деньги".

Ну, допустим, он действительно `мразь'. Это значит его надо оскорблять? А если какой-нибудь бомж на улице назовет вас .удаком, вы поднимите крик и начнете с ним ругаться?

anonymous
()
Ответ на: комментарий от anonymous

действительно, «фигурной» можно вычеркнуть.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.