jython-2.2

> опередлеение продуктиности

Затраченные на проект ДЕНЬГИ. Не все же здесь студиоузы-теоретики. Кто-то и реальные программы для родной компании писать должен.

> Конкретизируй условия, и требования

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

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

"миллионы леммингов не могут быть не правы" (с) :)))

> Ты же автора опусов про Яву считаешь, как я понимаю, дурнем,

Не-а, Гослинга я таковым не считаю. А вот Тейт - дурень , точно, раз его даже из IBM выгнали. :)

> Scala/Groovy/JPython/JRuby etc появляются потому, что писать на яве видимо скучновато ;)

И что это за критерий выбора языка "скучновато"? :))

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

Forth

>Основная идея - когда надо использовать JVM, а яву использовать не хочется / не удобно / нужно скриптовать

Scala, Groovy, чем не угодили?

>Основная идея - когда надо использовать JVM, а яву использовать не хочется / не удобно / нужно скриптовать

Scala, Groovy, чем не угодили?

Скажем приведи пример короткого скрипта на JRuby, а потом его аналог на Groovy, посмотрим, в чем же выгода написания на JRuby

> поскольку я жабабыдлокодер с кругозором уже 10 градусов поскольку я жабабыдлокодер с кругозором уже 10 градусов

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

Пойми, каждый может зарабатывать деньги любым легальным споосбом. Ожднако есть люди который пищут на яве/1С/Динамикс/Дельфи, а с свободоное время смотрят немного по сторонаим - чтобы мозги не затекали, есть те кто не смотрят (времени жалко), а есть те кто не только по сторонам смотрят, а еще и считают дурнями тех, кто смотрит и пытается думать (Тейта того же).

Ты, как я вижу, явно из третей группы. Тратить свое время, пытаясь что-то объяснить последним - бесмысленно. Их привычное средство разработки уже полнотсью съело им мозг. У меня тут есть один такой, до сих пор считает, что то с чем он работал 80-ых (PICK, multivalue database) - самое лучшее средство, изобретенное человечеством, а остальное все фигня.

> Основная идея - когда надо использовать JVM, а яву использовать не хочется / не удобно / нужно скриптовать

> Scala, Groovy, чем не угодили?

Больше - не меньше.

> Скажем приведи пример короткого скрипта на JRuby, а потом его аналог на Groovy, посмотрим, в чем же выгода написания на JRuby

Скала не скриптовый язык, а Ява с человеческим лицом. Груви имел плохую репутацию вечной беты. Примеры скриптов будут силно позже, как ревмя будет как раза пересмотрю все Jython/JRuby/Grooovy и сделаю вывод.

http://ru.wikipedia.org/wiki/Компилятор http://ru.wikipedia.org/wiki/Интерпретатор http://ru.wikipedia.org/wiki/JIT http://ru.wikipedia.org/wiki/Транслятор

В связи с этим, вместо термина «компилятор» иногда используют термин «транслятор» как его синоним: либо в старой литературе, либо когда хотят подчеркнуть его способность переводить программу в машинный код (и наоборот, используют термин «компилятор» для подчеркивания способности собирать из многих файлов один).

"Учись, студент"©Операция Ы

>В связи с этим, вместо термина «компилятор» иногда используют термин «транслятор» как его синоним

Вот только интерпретаторы - это тоже трансяторы :D Так что по твоей логике выйдет "интерпретатор" - синоним "компилятора".

Всякий компилятор - транслятор. Но не всякий транслятор - компилятор.

> Для начала: компилятор НИКОГДА НЕ ИСПОЛНЯЕТ ПОРОЖДЕННЫЙ ИМ КОД - это
> не его задача.

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

> Дальше: классический интерпретатор никогда не порождает НОВЫЙ КОД, а
> просто исполняет те машинные инструкции, которые зашиты в нем самом.

Простите, но я не говорил, что он порождает НОВЫЙ КОД. Как раз было
сказано обратное - переводит в машинные инструкции на лету.

>- транcляция - перевод с одного формального языка на другой

>- компиляция - трансляция в язык машинных кодов какого-то процессора (например ява-процесора, ага? :) sv75 (*) (28.08.2007 11:22:09)

Компиляция это вообще по-моему просто перевод с одного языка на другой. Перевод в java-байткод или аналогично в net перевод программы в cil -компиляция. Хотя для джава байткода существует даже процессор, исполняющий этот код. У джавы 2хступенчатая трансляция.

Еще существуют программы, переводящие с 1-го языка высокого уровня на другой. Например с паскаля на c++. С c++ на java.

>Ещё раз. Java никогда не была интепретатором. Компиляция и JIT - это две больших разницы. Не путайте тёплое и мягкое. А википедия - это тот ещё источник, ага :D

KRoN73 (*) (28.08.2007 10:21:25)

jit -самая натуральная компиляция. Неважно с чего переводят в машинный код - с языка высокого уровня или с байткода.

Кстати в java применяется более совершенный, чем jit механизм компиляции - Sun HotSpot. Там применяется многоуровневая оптимизирующая компиляция.

У java 2хступенчатый спосов выполнения- компиляция в байткод, затем трансляция байт-кода(например интерпретатором).

>особенно интересно, как интерпретатор будет интерпретировать следующую конструкцию:

>int f();

>int main()

>{ >f(); >}

Посмотри как JavaScript интерпретирует такое. Описание функции может быть в любом месте программы. Интерпретатор загружает всю программу в память и парсит все функции и глобальные переменные а уж потом выполняет их построчно.

> Посмотри как JavaScript интерпретирует такое.

Причем здесь JavaScript? Тролль говорил о Си. Но если уж JavaScript - ОК, какой именно интерпретатор ты имеешь в виду?

> Интерпретатор загружает всю программу в память и парсит все функции и глобальные переменные а уж потом выполняет их построчно.

Я знаю, как работают "интерпретаторы вообще". Какой _конкретно_ интерпретатор ты имеешь в виду?

> Посмотри как JavaScript интерпретирует такое. Описание функции может быть в любом месте программы. Интерпретатор загружает всю программу в память и парсит все функции и глобальные переменные а уж потом выполняет их построчно.

а с чего ты взял, что в этом файле будет объявление функции f() вообще? Каким образом процесс компиляции связан с исполнением и линковкой????

Ага придумали язык и компилятор для него под сферического коня в вакууме - и говорят "мы крутые!". А реальные компиляторы были и создаются под набор конкретных и уже существующих процессоров. И в этом реальная разница того же gcc и jvm + java +... что там ещё нужно для запуска программ написанных под java. Кроме того если уже есть такие нужные всем процессоры с native-java code, то почему бы там java и не применять, а всем остальным, пожалуйста, разрешите пользоваться C++/C на нормальных, простых, процессорах. Кроме уже сказанного добавлю, что не все владельцы обычных x86 или ARM готовы платить временем выполнения за мифическую докомпиляцию до native-instructions в процессе запуска программы. Кроме того, я сильно сомневаюсь что тот супер оптимизирующий компилятор что работает в современных реализациях java использует время эффективнее чем тот же gcc (не realtime!). Вы видели как компилируется код с большим числом template + STL + -O3. Небось java + её под системы круче придумали? И ещё если очень вам хочется под процессоры с native-java instructions программы писать, я бы рекомендовал добавить поддержку этого процессора к куче уже поддерживаемых в gcc, чем тащить чистую java + все её прелести туда же. Мне почему-то кажется что эффект будет заметнее. Особенно это будет заметно в силу политической обстановки: я практически не сомневаюсь что такие процессоры будут делать намного мощнее обычных, ну чтобы сказать что java это круто. И тут gcc покажет что почём :-)

>Каким образом процесс компиляции связан с исполнением и линковкой????

Оригинальный вопрос был про интерпретацию куска кода. Почему ты спрашиваеш ь о компиляции?

>а с чего ты взял, что в этом файле будет объявление функции f() вообще?

В JavaScript функция может быть объявлена в любом файле. Главное что интерпретатор составляет хэш всех глобальных функций чтобы потом не парсить все инклуды.

Решил проверить на сколько Jython медленнее Python. И какого же было мое удивление, когда оказалось, что все в точностью да наоборот. Jython в 3 раза (!) БЫСТРЕЕ Python.

Вот резулютаты тесвот:

$ cat > t2p69.py
f = open("t2p69.out", "w", 0)
f.write(str(2**999999))
f.close()

$ time python t2p69.py

real 1m33.730s
user 1m34.110s
sys 0m0.020s

$ time jython t2p69.py

real 0m29.990s
user 0m31.930s
sys 0m1.760s