Clojure - lisp для JVM

Кучка классов собирается в jar архив, идиот. И это удобнее, чем exe, ибо вытащить объектный файл из exe это задача на чемпионат мира по программированию, в то время как jar = прозрачный и удобный zip архив. Любой класс можно вытащить/втащить/заменить/проабдейтить без гемора как вручную, так и программно. Даже линкера как-такового нет (простой архиватор).

Пошел от сюда, вантузятнег!

>mono (*) (18.10.2007 22:29:56)

ААА! Красавчик! А я о тебе как раз вспоминал. Эта тема не могла обойтись без такого выродка, как ты.

>Кажется этот exe-шник и содержит байткод. Просто для пользователя exe удобней чем кучка .class-ов, а так это одно и тоже.

Ну да.
А пользователям удобнее jar-файлы пересылать и инсталлировать в мобильники, чем заниматься экстракцией exe в Wine. Ж))

>Пошел от сюда, вантузятнег!

О! А ты видимо горишь желанием писать софт под новую версию windows?

Кажется этот exe-шник и содержит байткод. Просто для пользователя exe удобней чем кучка .class-ов, а так это одно и тоже.

Кажется? Очнись. Ссылку http://www.linux.org.ru/view-message.jsp?msgid=2173329&page=3 даже здесь давали

>Про Ngen и AOT тебе так же напомнить? Мама тебе точно читать запрещает!

JIT compilation is considered advantageous in many scenarios because of its portability, flexibility and performance. The only major drawback is the startup time delay. Various technologies exist for reducing this delay. "Native Image Generator" (Ngen.exe) by Microsoft is one of the examples. Ngen pre-compiles (or pre-jits) bytecode in a Common Intermediate Language image into machine native code. As a result, no runtime compilation is needed. .NET framework 2.0 shipped with Visual Studio 2005 runs Ngen.exe on all of the Microsoft library DLLs right after the installation. Pre-jitting provides a way to improve the startup time.

http://msdn2.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

.NET компилирует C# в натив!!

Да... Мало нам здесь было Лисперов vs C/C++ vs Java, тут еще и фанаты .Net повыползали из своих IDE! Пипец что тварится!

>ААА! Красавчик! А я о тебе как раз вспоминал. Эта тема не могла обойтись без такого выродка, как ты.

ну хоть кто-то обо мне помнит..

>.NET компилирует C# в натив!!

В натив чего??? C# компилируется в байт код, который выглядит как экзешник. При запуске экзешника JIT компилирует его в нативный код, которыл лежит в оперативной памяти. Именно он и исполняется.
А сам экзешник остается байт кодом.
Для тех кто не верит.
1)делаем прогу hello woerld в вижуал студии.
2)компилируем ее в exe.
3)запускаем в линуксе через моно.
4)наслаждаемся кроссплатформенностью.

Какой нахрен натив???

>Попытайся там найти кариес чисто визуально.

Не нашел. Просвети убогих сппшников, о великий жабофил.

З.Ы. Вместо того, чтоб не ср%ть, где попало, и аккуратно обращаться с массивами и пр., вы выбираете супер-мега-инструмент жабу, которая будет за вас думать. Я правильно понял мысль?

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

А про -server опцию не слышал? С ней ВЕСЬ код компилится при старте

>Те же результаты можно получить, если генерировать сишный код, а потом его прогонять через gcc. Получаем и нативность, и все gcc-шные оптимизации.

Ты сам то вериш в этот бред?

>FreeBSD, NetBSD, OpenBSD, Tru64, HP-UX, BeOS, NeXTstep, IRIX, AIX и кучу других операционок????

У всех вышеперечисленных (кроме бздей и beos-не знаю как там) есть нормальная жаба не от сана. и на многих других тоже.

>"Кроссплатформенность" Явы - это фикция

Эта фикция лично у меня работает на Win/Lin/Solaris разных версий/AIX/Irix/OSX/OS9.

Классная фикция.

>2400 строк. Правда на Perl'е. Если хочешь - пришлю)

Вот когда займешься проектиком лет на 5 под пол миллиона LOC( что такое метрика LOC гугли) под все эти платформы - тогда придешь сказки рассказывать про GCC, Qt и прочие C.

>Разве так сложно поддерживать бинарники для трех-четырех платформ, на которых работает JRE?

Под все что ты перечислил и даже больше JVM есть. И весьма качественные. Некоторые даже круче сановских.

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

Моя мысль в том, что скроее всего не существует программ на java которые Вы бы хотели видеть на c++. Что, смотрелок джпегов на С++ нет? или игр?

>Может быть и не сложно, но всё равно это дополнительная трата времени программиста.

Пускай напишет кросплатофрменный ifconfig, а потом несет чушь про "несложно". А то ведь он до сих пор везде разный. 100 лет в обед.

Теоретики блин. Вы уже портанули все библиотеки с одинаковым апи под все платформы?

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

>А про -server опцию не слышал? С ней ВЕСЬ код компилится при старте

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

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

Упс! Дык, это ж всё про жабу ты рассказал:)

>А про -server опцию не слышал? С ней ВЕСЬ код компилится при старте

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

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

>>Ты хоть одну программу в жизни написал больше 10 тысю строк?

>Ну ты то их пишешь каждый день. Пшел нах зассаныч!

Не гони на Саныча: он не пишет, он диктует, а "пишет" его секретарша(ы). И если пишут мало, он их подгоняет: "Пеши йесчо!":)

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

Посмотри на попытки сделать такое для Erlang и почитай, почему проект загнулся:)

> А на мобилниках стоит Ява. Программы для них пишутся на Ява,

Только про "Яву на мобилках" зведень не надо, неуч:)

>Посмотри на попытки сделать такое для Erlang и почитай, почему проект загнулся:)

Что за проект? (не флейма ради, просто интересно)

>Под все что ты перечислил и даже больше JVM есть. И весьма качественные. Некоторые даже круче сановских.

Да ладно? gcj, Apache harmony, Kaffe, ikvm.net? Я на них с горем пополам и тормозами еле jedit запустил (а на некоторых не запутилось вовсе). И про совместимость не гони: IBM SWT мало совместима со Swing API.

Нечайно наткнулся: http://erlgtk.sourceforge.net/

Делать людям нечего)

>Что за проект? (не флейма ради, просто интересно)

Коротко - вот здесь

http://web.telia.com/~u83304791/erlang_faq/faq.html

(в частности, п. 8.5)

А проект Erlang to C (запамятовал название и закладки сейчас не нахожу у себя) - поищи в гугле. В двух словах - проект был вполне рабочий. Загнулся из-за бесперспективности - почти всё сложнее hello.erl выполнялось медленнее, чем байткод под erl. А с появлением в основной ветке Erlang'a HIPE о "конвертировании *.erl в *.c" стало говорить вобще неприлично (как в доме повешенного о верёвке):)

>Нечайно наткнулся: http://erlgtk.sourceforge.net/

>Делать людям нечего)

Ну, дык, может для них Tk "несимпаааатичныыый!":)))

>Да ладно? gcj, Apache harmony, Kaffe, ikvm.net?

на просвятись

http://schmidt.devlib.org/java/jdk-jre.html

http://schmidt.devlib.org/java/standalone-vm.html

http://schmidt.devlib.org/java/embedded.html

http://schmidt.devlib.org/java/jit-compilers.html

>И про совместимость не гони: IBM SWT мало совместима со Swing API.

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

> но поскольку IExplorer основной браузер, и апплеты он поддерживает плохо

0_o! IExplorer как раз таки поддерживает апплеты лучше всего. Только на нём при разработке апплетов я не испытваю трудностей. Файерфокс не умеет правильно обрабатывать апплет с множественными JARами (archive="applet.jar, lib1.jar, lib2.jar"), а Опера криво работает с параметрами GET/PUT, которые криво парсятся в HTTPRequest на сервлете.

>>И про совместимость не гони: IBM SWT мало совместима со Swing API.

>После этого утверждения выдаю справку - ты совсем не сейчешь в вопросе про который высказываешься.

Сознаюсь, на счет GUI мало осведомлен. Но помню статью, в которой была эта фраза.

ngen

mono --aot

RTFM, LMD!

>Загнулся из-за бесперспективности - почти всё сложнее hello.erl выполнялось медленнее, чем байткод под erl. А с появлением в основной ветке Erlang'a HIPE о "конвертировании *.erl в *.c" стало говорить вобще неприлично (как в доме повешенного о верёвке):)

Ну что я могу сказать, после прочтения http://user.it.uu.se/~kostis/Papers/hipe-sttt.pdf и ftp://ftp.csd.uu.se/pub/papers/reports/0136.ps.gz ... Такое впечатление, что разница в скорости в несколько раз между BEAM/C и HIPE скорее всего вызвана вовсе не использованием C как промежуточного языка, а кривостью самого BEAM/C. Потому что ETOS (транслятор эрланга в схему + Gambit-C) в большинстве тестов работает также быстро, как и HIPE.

PS Я вовсе не призываю выбросить подход с байт-кодом в биореактор :), просто когда говорят, что компиляция в С работает в 10 раз медленнее чем JIT компиляция байт-кода, только потому что используется C в качестве промежуточного языка, это выглядит по меньшей мере странно (все же С достаточно низкоуровневый, приближенный к аппаратуре язык)

>разница в скорости в несколько раз между BEAM/C и HIPE скорее всего вызвана вовсе не использованием C как промежуточного языка, а кривостью самого BEAM/C. Потому что ETOS (транслятор эрланга в схему + Gambit-C) в большинстве тестов работает также быстро, как и HIPE.

А ты разницы между Scheme и C не видишь?:)

>Я вовсе не призываю выбросить подход с байт-кодом в биореактор :)

HIPE в Erlang и даёт нативный код. но только там, где он действительно нужен:)

>А ты разницы между Scheme и C не видишь?:)

Напомню, что Gambit-C компилирует схему в С. Поэтому комбинация транслятора эрланга в схему и Gambit-C есть не что иное, как компилятор эрланга в С.

> не хватает еше Java на Java, вот был бы рулез. Как его там JaJa ?

ЖА-ЖА!!11 ЧО-ЧО!!!!111 Попячса или смертъ!!!!110!!1010000101

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

>Моя мысль в том, что скроее всего не существует программ на java которые Вы бы хотели видеть на c++.

Тогда java не нужна? Раз ничего лучшего по сравнению с c++ она не даст.

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

читал я эти маркетинговые саносказки...

> Теперь объясни мне, как твой linux-бокс запустит программу, если загруженный им бинарь будет оканчиваться на .exe?

а нахуя мне запускать загруженный хрен знает откуда бинарь?

> Тогда даже можно Linux.org.ru переписать грамотно, так, что не придется грузить 50 сообщений на клиента при каждом обоновлении страницы, а только последние появившиеся 5-10 сообщений, а остальные 50 держать в кэше браузера и рендерить страницу из кэша. Web 2.0 слышал?

если это можно написать и на жабаскрипте, зачем использовать небезопасные апплеты? их ведь не из прихоти микрософта перестали использовать

> если это можно написать и на жабаскрипте, зачем использовать небезопасные апплеты?

С каких пор жабаскрипт безопаснее апплетов?

> их ведь не из прихоти микрософта перестали использовать

И из-за сопротивления Микрософт - тоже. MS продвинула ActiveX и свернула поддержку Явы.

>> если это можно написать и на жабаскрипте, зачем использовать небезопасные апплеты?

> С каких пор жабаскрипт безопаснее апплетов?

жабоскрипт умеет читать пользовательские файлы?

> жабоскрипт умеет читать пользовательские файлы?

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

>> если это можно написать и на жабаскрипте, зачем использовать небезопасные апплеты?

> С каких пор жабаскрипт безопаснее апплетов?

>абоскрипт умеет читать пользовательские файлы?

Аплеты не могут читать пользовательские файлы. Они могут только разговаривать по http с тем сайтом откуда они были загружены.

>Сознаюсь, на счет GUI мало осведомлен. Но помню статью, в которой была эта фраза.

Переведу на сишный:

gcc непереносимое потому что Qt несовместим с GTK.

>а нахуя мне запускать загруженный хрен знает откуда бинарь?

Ты каждый день это делаешь! Взять хотя бы flash. JavaScript -это точно такаяже виртуальная машина. Ты сомневаешься что есть в секторе где люди работают необходимость юбольше чем флешики пускать? Так вот она есть.

>если это можно написать и на жабаскрипте, зачем использовать небезопасные апплеты? их ведь не из прихоти микрософта перестали использовать

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

>жабоскрипт умеет читать пользовательские файлы?

Представь себе. ДОгадайся что такое new ActiveXObject("Scripting.FileSystemObject") под вендой, или Components.classes["@mozilla.org/file/local;1"].createInstance(Components.inter faces.nsILocalFile); под мозиллой.

>> жабоскрипт умеет читать пользовательские файлы?

> Представь себе. ДОгадайся что такое new ActiveXObject("Scripting.FileSystemObject") под вендой, или Components.classes["@mozilla.org/file/local;1"].createInstance(Components.inter faces.nsILocalFile); под мозиллой.

понял, ушёл ставить NoScript :)

> понял, ушёл ставить NoScript :)
Лучше сходить почитать :)

> >Иди и скомпили JVM под свою архитектуру и не воняй

> Ага. Товарисчи с http://www.freebsd.org/java/ уже несколько месяцев портируют jvm 6. Понаписали тучу патчей, и до сих пор не готово. Ты предлагаешь мне заняться этим вручную? А если бы у меня был Plan9? Молчи лучше, компилятор хренов.

В чем проблема? Там только Си, котрый легко поддерживать для нескольких платформ. ;-)