jython-2.2

да там все слова не наши. смотрите латынь.

> интерпретатор выполняет комманду за коммандой, ему все равно что в остальных файлах (если он их еще не выполнил :-).

Это тебе KRoN73 сказал, да? Так вот - он ошибся.

> интерпретатора C и уж тем более С++ не бывает. По простой причине! Потому что эти языки впринципе не интерпретируемые.

Тебя зобанели в Гугле за плохое поведение в детском саду?

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

>KRoN73 не позорься, язык не бывает интерпретируемым или компилируемым, это свойство _реализации_

Цитирую себя же:

"В отличии от Ваших вариантов, по которым у нас одна и та же реализация языка то транслятор, то компилятор ..."

>В приведенном тбой случае x86-эмуляторе на ARM-процессоре будет интерпретатором, как при исполнении x86 программ на x86 процессоре интерпретатором будет процессор

Всё же, проблемы с логикой и причнно-следственными. Хвост виляет собакой. Реализация языка (GCC-4.3.1 для примера) становится то интерпретатором, то компилятором, в заивисимости от того, где исполняется её код.

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

вопрос этого где-нибудь! в случае интерпретатора эта функция f должна быть уже проинтерпретирована интерпретатором. А в случае компилируемого языка она может быть откомпилирована намного позже.

Господа, да не поддавайтесь вы на провакации:) А человеку, который предложил этот тупой пример с функцией f предлагаю сначала набрать этот самый пример и попытаться откомпилировать хотя бы. И посмотреть, сколько ошибок найдет в нем компилятор, если самому это не по силам

>Хотелось бы сделать уточнение.

>По русскоязычной формальной терминологии, как я понимаю

Тут не всё так просто. Формально трансляций - перевод. Компиляция - сборка из мелких компонентов. Но в терминологии языков программирования эти термины приобрели свой конкретный смысл. Хотя, вот, у многих в этом топике, эти термины вообще не несут за собой смысла. У них всё, что быстрое - то компиляторы :D Ну, в таком случае в некоторых (хотя и не частых случаях) Java - более компилятор, чем GCC :D

>Вы читали вообще предыдущие посты? Или просто выборочно выдираете фразы из контекста

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

>Контроллеры java и так достаточно распространены. Хотел было рассказать о них кое-что, да передумал, когда прочитал вторую часть Вашего опуса. ЛОР есть ЛОР:(

Приведи ссылочку на характеристики, чтобы я мог сравнить их производительность

>Компилятор java генерирует НАТИВНЫЙ код для Java-процессора.

Я это и пытаюсь доказывать в этой теме.

Что же касается Вашего "ВСЕГДА" - то речь там шла не о Яве. А вообще. Что есть бред. Ибо нативный код генерируется не всегда. Независимо от того, на каком процессоре будет выполняться. Хотя можно, конечно, притянуть за уши гипотетические "ещё не созданные" процессоры, но тогда _любой_ бинарный код можно будет назвать нативным. Тогда по бритве Оккама этот термин просто придётся выкинуть.

>Как я уже сказал постом выше, компиляция ВСЕГДА происходит в НАТИВНЫЙ код, иначе какой от этого компилятора толк.

В какой нативный код компилирует, скажем, компилятор PHP?

>Господа, да не поддавайтесь вы на провакации:) А человеку, который предложил этот тупой пример с функцией f предлагаю сначала набрать этот самый пример и попытаться откомпилировать хотя бы. И посмотреть, сколько ошибок найдет в нем компилятор, если самому это не по силам

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

>Взял программу на Python, скомпилировал ее в байт-код (pyc-файл). Опять я взял и скомпилировал.

>НО Python интерпретируемый язык, а C нет... в чем же между ними разница? Уж тоно не в возможности скомпилировать :-)))

Питон - компилирующий язык :)

KRoN73, как славно, что Вы опять появились:) Столько Вы всего тут наговорили, что придется самое интересно припомнить. Итак:

>Не всегда. Трансляция Java-программы в байткод не приводит к появлению нативного кода

Вы все еще так считаете? т.е. байткод не является нативным? И все это после стольких упоминаний о многострадальных java-процессорах. И еще:

>Как показало общение в этом топике, некоторые индивидумы элементарно путают компиляцию вообще с компиляцией в нативный код. Простейший контрпример я уже привёл - Java-байткод

Т.е. Вы считаете, что есть 2 типа компиляции: 1) Компиляция вообще 2) Компиляция в нативный код

Я так понимаю, Вы думаете, что компилятор java - это который "вообще", а gcc, например, это "нативный"?

> Питон - компилирующий язык :)

язык может быть интерпретируемым и с этим поспорить нельзя

то что программу на языке python можно скомпилировать, с этим тоже поспорить нельзя. А можно ее не компилировать, а интерпретировать. Комманду за коммандой.

то что нельзя написать интерпретатор языка c или с++ с этим можно поспорить, но написать нельзя :-)

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

> Я так понимаю, Вы думаете, что компилятор java - это который "вообще", а gcc, например, это "нативный"?

Но видимо переходит в разряд "вообще" когда является кросскомпилятором.

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

Да, когда-то по учебникам нас учили именно так. Но народ тут в приступе нигилизма учебники не признаёт :) Приходится обращаться к иным трактовкам :)

> то что нельзя написать интерпретатор языка c или с++ с этим можно поспорить, но написать нельзя :-)

а... так ты просто тролль, понятно.

>Если ты не читал предыдущего поста - это не делает Си интерпретатором. Но твой эмулятор вполне может оказаться именно интерпретатором.

Но спор начался с утверждения, что Java - интерпретатор. Java, а не JVM. И я изначально говорю _только_ о языках программирования. А что касается сред исполнения - так сегодня и практически все процессоры - интерпретаторы.

>>Не всегда. Трансляция Java-программы в байткод не приводит к появлению нативного кода

>Вы все еще так считаете? т.е. байткод не является нативным? И все это после стольких упоминаний о многострадальных java-процессорах.

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

>Я так понимаю, Вы думаете, что компилятор java - это который "вообще", а gcc, например, это "нативный"?

"Нативность" кода относится только к среде исполнения. Если среда способна выполнять код без трансляции, то он - "нативный".

Для x86 в контексте которого в тот момент шло обсуждение, Java-байткод не нативный. Для некоторых Java-процессоров - нативный.

>>Зачем нужен еще один "скриптовый недоязычок" ((с) VSL), да еще на Java? Программирование ради программирования?

>Программирование ради массовых практических задач.

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

>язык может быть интерпретируемым и с этим поспорить нельзя

Пардон, опять недовысказал мысль. Естественно, речь идёт об оригинальном python 2.x от Гвидо :)

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

А уже не раз упомянутый Форт - вообще переключает оба подхода по воле программиста.

Когда я тут упоминаю "язык", то всегда имеется в виду "реализация языка". Пару раз упоминал это явно, но повторяться в таких объёмах задалбывает :)

> спор начался с утверждения, что Java - интерпретатор. Java, а не JVM. И я изначально говорю _только_ о языках программирования.

Да, ты мастер жонглировать терминами. Только вот скажи: если ты говорил о Java как языке программирования, то причем здесь вообще компиляторы или интерпретаторы? Это _язык_, спецификация, которую можно реализовать как в виде интерпретатора, так и в виде компилятора в байтлод/машкод. Но ты кинулся доказывать, что Java никогда не была интерпретатором... Ладно, всё понятно - духа признать ошибку не хватило.

>>> Зачем нужен еще один "скриптовый недоязычок" ((с) VSL), да еще на Java? Программирование ради программирования?

>> Программирование ради массовых практических задач.

> Каких конкретно?

Любых, если манагер не требует писать на ява ;)

>Но спор начался с утверждения, что Java - интерпретатор. Java, а не JVM. И я изначально говорю _только_ о языках программирования. А что касается сред исполнения - так сегодня и практически все процессоры - интерпретаторы.

Ну вот, положительная динамика в Ваших суждениях уже чувствуется :) Только Вы все равно еще хитрите, применяя выражения "Java - интерпретатор", ибо под Java много чего можно подразумевать. Я в третий раз повторю мои слова (которые Вы как будто не замечаете), сказанные еще задолго до Вашего появления в топике:

>Компилятор в java есть, с этим никто не спорит: это программа, транслирующая исходный текст на ЯЗЫКЕ ПРОГРАММИРОВАНИЯ JAVA (высоуровневый ООП-язык) в байт-код. Все, на этом работа компилятора закончена

и еще одна моя фраза:

>В Java есть компилятор, но это всего лишь ПРОМЕЖУТОЧНЫЙ ЭТАП

То, что программа на ЯЗЫКЕ ПРОГРАММИРОВАНИЯ JAVA компилируется - с этим никто и не спорил. Спорили больше о процессе, который следует за компиляцией, так что Вы не путайте. Но хотя бы тут ясность появилась:)

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

путаница в головах возникает от того, что книги не читают..

просто процесс очень сложный... и не всем дается.. например python :-)

когда интерпретатору дается строчка (или блок) он ее компилирует в байт-код, а потом этот байт-код исполняет(интерпретирует).. в байт-коде может встретиться комманда типа exec "a=1" и тогда ему придется откомпилировать "a=1" в байт-код и проинтерпретировать получившийся результат. То есть на примере мы видим как тесно переплетаются процесс компиляции и интерпретации. (я уж не говорю, что весь этот процесс может интерпретироваться на эмуляторе x86, который работает на эмуляторе.. .. инструкции которого интерпретируются.. и все это для ускорения компилируется в "нативный" код.. который исполняется на эмуляторе.. а потом это все распечатывается на бумажку в виде инструкций взять яблоко из одной карзины и положить в другую и выполняется ротой солдат)

> Контроллеры с программами на асме - это такая экзотика....

Да уж куда деваться. Контроллеры с ява-машиной на борту меньшая экзотика, да?

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

Или думаете, таких контроллеров применяется меньше, чем контроллеров, поддерживающих ява?

> Спорили больше о процессе, который следует за компиляцией, так что Вы не путайте.

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

>> Спорили больше о процессе, который следует за компиляцией, так что Вы не путайте.

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

Ура, телепаты вернулись из отпуска!

> Любых, если манагер не требует писать на ява

И насколько это более продуктивно? Надо все обосновывать, доказывать, как учил нас безвременно покинувший наш форум Профессор В.С.Лугоффский. Хоть сам он так и не обосновал (IMHO:)) свою "Схему" для задач создания веб-интерфейсов, но попытку сделал. Иначе - просто "информационный шум" (с) VSL.

>Для x86 в контексте которого в тот момент шло обсуждение, Java-байткод не нативный. Для некоторых Java-процессоров - нативный.

Не успел Вас похвалить, как Вы опять за свое взялись. Компилятор всегда генерирует нативный код, а то, что "нативность" - понятие относительное это и ребенок понимает. В общем, я уже приводил пример, где на Пентиуме разрабатывается софт для КПК на ARM. По Вашему мнению генерируемый ARM-компилятором код является НЕ нативным, ибо он не x86. Это в корне не верно, нативность - это совсем другое, и я писал что это такое. Лично я могу припомнить лишь один компилятор, который генерил код, не нативный по отношению к процессору, на котором программа впоследствии выполнялась. Это компилятор Visual Basic (до 5 версии). Вот он генерил exe-файлы под платформу x86, однако код (р-код) был для x86 не нативным, поэтому его очень часто псевдокодом звали

> Пардон, опять недовысказал мысль. Естественно, речь идёт об оригинальном python 2.x от Гвидо :)

других питонов не бывает Гвидо -- Бог (питонов)

наверное можно изменить язык python так, что уже ни один интерпретатор его не сможет проинтерпретировать :-)

и наверное можно изменить c++ так что можно будет написать интерпретатор...

а еще можно изменить python так чтобы он стал c++, но на то существуют некоторые слоглашения и стандарты :-)

в случае с с++ все просто, есть стандарт и форвардные декларации там описаны и ни один интерпретатор с ними реализовать нельзя, т.к. интерпретатор "выполняет комманду за коммандой".

в случае с питоном нет стандарта, но есть Гвидо -- дедушка языка, который определяет некоторый основные принципы по которому построен язык. Про который написано, что он интерпретируемый.. (в документации по языку). И если это основное свойство языка убить, то будет уже другой язык.

>Только вот скажи: если ты говорил о Java как языке программирования

http://www.linux.org.ru/jump-message.jsp?msgid=2107420&cid=2108770

Для любящих жонглировать терминами, уточняю, что под "Java" во всём контексте имелся в виду транслятор sun-jdk. Конкретные реализации.

>То, что программа на ЯЗЫКЕ ПРОГРАММИРОВАНИЯ JAVA компилируется - с этим никто и не спорил. Спорили больше о процессе, который следует за компиляцией, так что Вы не путайте.

Рекомендую перечитать топик сначала.

>Компилятор всегда генерирует нативный код

Тогда понятие "нативный" теряет смысл. См. выше.

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

Я и пытался намекнуть, что для большинства людей такие ужасы назывались МК61 и остались в далеком детстве, и являются не менее экзотичными, чем ARM926EJ-S.

>Тогда понятие "нативный" теряет смысл.

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

>НАТИВНЫЙ КОД - это код, который процессор способен непосредственно исполнить. Нативный код - это НЕ та система команд, которая используется на компьютере, на котором работает компилятор

НЕПОСРЕДСТВЕННО, вот главное слово, т.е. без посторонней помощи.

Имеем процессор Pentium, компилятор java. Так вот сгенеренный им код является нативным, несмотря на то, что он и не является x86 кодом. По отношению к процессору Pentium он является Не нативным, но процессор тут совершенно ни при чем. Мы пишем программу с намерением запустить её на процессоре java. Вот если бы java-компилятор начал бы генерить x86 код, а на нашем java-процессоре работал бы x86 эмулятор, вот тогда сгенеренный компилятором код можно было бы назвать не нативным. Но это уже на грани фантастики

>Я и пытался намекнуть, что для большинства людей такие ужасы назывались МК61 и остались в далеком детстве, и являются не менее экзотичными, чем ARM926EJ-S.

Скажите тоже:) Как можно сравнивать старый-добрый MК-61 с монстром ARM926EJ-S? :)) Жаль, что блок питания к "Электронике" сгорел, надо перепаять будет, да стариной тряхнуть как-нибудь:)

> Тогда понятие "нативный" теряет смысл. См. выше.

такого общепринятого термина вообще нет. Нативным кодом __как правило__ называют некоторый код "родной" для среды исполнения.

Например, инструкции x86 для процессоров x86. Байт-код для виртуальной машины java. Спорить можно долго насколько набор инструкций x86 "нативный" для современных процессоров :-) и на сколько байт-код нативный вообще :-)

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

код называется "нативным", если... существует среда исполнения этого кода в которой он (код) исполняется без трансляции в комманды среды исполнения. или.. код называется нативным, если состоит из комманд среды в которой он исполняется. :-)

>> Любых, если манагер не требует писать на ява

> И насколько это более продуктивно?

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

Ты же автора опусов про Яву считаешь, как я понимаю, дурнем, так что видимо тебе бесполезно убеждать в том, что ява - это язык, на котором люди с кругозором шире 10 градусов пишут только если менеджер приказал или еще какая жестокая нужда заставила ;) И Scala/Groovy/JPython/JRuby etc появляются потому, что писать на яве видимо скучновато ;)

процессоры, которые исполняют его нативно - это уже прошлое.

JIT - компиляция - это настоящее и будущее. Некоторые до сих пор думают, что ВМ Ява и .Net побайтно интерпретируют байт-код. Какие наивные из 10-летнего анабиоза!

Современный подход: Исходный текст -> Байткод (Промежуточное компактное представление, не предназначенное для интерпретации!!!) -> Компиляция в НАТИВНЫЙ код (причем ОДИН раз с оптимизациями под ЗАДАННЫЙ ПРОЦЕССОР) -> Выполнение НАТИВНОГО КОДА под управлением Виртуальной машины...

> Я и пытался намекнуть, что для большинства людей такие ужасы назывались МК61 и остались в далеком детстве, и являются не менее экзотичными, чем ARM926EJ-S.

Это не ужас, а вполне типичный представитель буржуйского электронпрома, ATTiny13 производства Atmel. Такие контроллеры ставят в интеллектуальные датчики и низкоскоростную периферию, да вообще везде, где его возможностей хватает. Огромные плюсы оного контроллера - микроскопические размеры и цена в районе 30 центов в оптовых партиях при ~8MIPS реальной производительности и очень удобной архитектуре, обуславливающей быструю разработку.

>А мсье хоть когда-нибудь слышал про Java-процессоры

а зачем java-процессорам виртуальная машина? на них байткод не интерпретируется, но выполняется, он (код) для данного процессора родной, всё дело как раз в присутствии ВМ.

вот скажите, что будет делать виртуальная машина без JIT (!) (java -Xint) с переданным ей байткодом, может быть всё же интерпретировать?

только не нужно отвлекаться на то, что такие режимы почти ни кто не использует, мы же говорим про "концепции языков программирования" =)

а про то, что java компилятор именно _компилирует_ в байткод ни кто особо и не спорит

>Современный подход: Исходный текст -> Байткод (Промежуточное компактное представление, не предназначенное для интерпретации!!!) -> Компиляция в НАТИВНЫЙ код (причем ОДИН раз с оптимизациями под ЗАДАННЫЙ ПРОЦЕССОР) -> Выполнение НАТИВНОГО КОДА под управлением Виртуальной машины...

Вы, уважаемый, что-то перемудрили. В виртуальной машине выполняется как раз байт-код, нативный же код выполняется уже непосредственно процессором, иначе нахрена собственно JIT был нужен:) А про Java-процессоры, это Вы ляпнули не подумав. Для того, чтобы работал JIT нужна среда выполнения Java, которая в свою очередь предполагает наличие "большой" современной операционной системы. Ну а ОС предполагает наличие компьютера:) И Вы все это хотите запихать в небольшое встраиваемое устройство? Думаете это будет лучше, чем использовать всего одну микросхему? P.S. Ну не одну конечно, но в любом случае гораздо копактнее полноценного компьютера

Виртуальная машина - он же Фреймворк. Современные ВМ (Фреймворки) переводят байткод ОДИН РАЗ (по тербованию) в машинный код конкретного процессора и передают управление процессору. При этом, в отличие от неуправляемого кода, они контролируют это управление: Сборщик мусора Полный контроль над выделенной памятью

Процессор уж не может следить за потерянными ссылками. Это уже практически невозможно сделать...

В некоторых экспериментальных ВМ (SSCLI) есть понятие CodePitching, когда долго неиспользуемые блоки машинного кода удаляются из памяти.

> Современные ВМ (Фреймворки) переводят байткод ОДИН РАЗ (по тербованию) в машинный код конкретного процессора
Ваша не правда. байткод в _современных_ ВМ может:
1. Никогда не быть транслированым в машиный (например код загрузчика который отрабатывает один раз при старте приложения).
2. Код метода может быть _частично_ переведен в машинный.
3. Код, однажды переведенный в машинный, может быть заного отранслирован с учетом новой информации по оптимизации (банально выяснилось, что переменные не выходят за рамки треда и локи не нужны).

> Питон - компилирующий язык :)

Перл был компилирующим за годы до создания питона.

Есть ява терминалки... без "Большой операционной системы"

>Перл был компилирующим за годы до создания питона.

Ну, Питон - тоже не ребёнок по возрасту, так что что там было в допитоновые времена на Перле - не знаю, но сейчас он безусловно использует компиляцию в байткод перед исполнением, как и Питон.

>С моей точки зрения разница интерпретатора и компилятора в том (в обзем случае, так сказать грубо говоря), что интерпретатор выполняет команды одну за одной (ну или небольшие блоки) переводя их на лету в машинные инструкции, а компилятор сначало всю программу переводит в машинный код и только потом исполняет. Надеюсь это хоть как то развеет Ваши сомнения/недопонимания.

Для начала: компилятор НИКОГДА НЕ ИСПОЛНЯЕТ ПОРОЖДЕННЫЙ ИМ КОД - это не его задача. Дальше: классический интерпретатор никогда не порождает НОВЫЙ КОД, а просто исполняет те машинные инструкции, которые зашиты в нем самом. Продолжим: с появлением JIT и NET (Чур меня!) появилась возможность на ходу компилировать 3.14-код в машинные инструкции и это как-бы размыло разницу между классической компиляцией и интрепацией, потому что jitc поначалу работает как компилер и линкер одновременно, а потом просто передает управление порожденному коду. Вроде как получается, что по скорости, теоретицки, жаба догоняет Це, но это только теоретитьки (извините - фефекты ечи) на самом деле об оптимизации такого кода можно забыть навсегда (опять же теоритиски). На закуску: JIT-коммилятор никак не может быть VM(виртуальной машиной), потому что он не интертепатор P-кода, а компилятор машинного кода. Арривидерчи, синьер Панталоне!