jython-2.2

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

Я боюсь, что если для тебя это два интерпретатора и тебя это смущает - то ты уже не сможешь этого понять, серьезно. Основная идея - когда надо использовать JVM, а яву использовать не хочется / не удобно / нужно скриптовать. Кстати надо еще посмотреть, может оно в байткод стало компилировать, ты про интерпираторы точно проверил?

> По мне - всё, что не даёт на выходе хорошо оптимизированный по скорости и размеру машинный код - интерпретатор

А теперь иди читать про JIT и думать. Хотя похоже что ассемблер уже съел твой мозг безвозвратно :(

Наверное я этим постом не лучшим образом буду смотреться, но ради подравнивания одиозных долбоебов, считающих себя охуенными программерами, скажу следующее:

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

Сорри, но меня вывело то сообщение про резюме и т.д.

> Например, какой-то Мартин Фаулер ,"прославившийся" тем ,что написал какую-то книжку по рефакторингу, с примерами на быдлоязычке, сотоварищи выпустил давеча релиз продукта на jruby. Безумцы!

То есть на самой яве писать они все-таки подутомились?

> как следствие, отвечаете не на вопрос, а на строчки и отдельные фразы из формулировки,

А что делать, если вопрос задан так, что неявно предполагает ряд бредовых утверждений? Это вызывает соотвествющую реакцию (а вопрос был типа "почему же линукс такой хлам?" :)

>А что делать, если вопрос задан так, что неявно предполагает ряд бредовых >утверждений? Это вызывает соотвествющую реакцию (а вопрос был типа "почему же >линукс такой хлам?" :)

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

А во-вторых, на бредовые вопросы обычно либо вообще не отвечают, либо отвечают встречным вопросом об уточнении смысла заданного :) Под бредовыми вопросами я понимаю те, в формулировке которых применяются нанадлежащие понятия. Хотя даже в этом случае, ответить можно, предвосхищая смысл заданного. Многим из нас иногда приходится отвечать на вопросы типа "как запустить интернет?" или "а почему компьютер моргает?" Имхо: профессионал должен уметь отвечать на любые вопросы, даже в тех случаях, когда предполагается многовариантность ответа.

А разве реализация java по аналогии с gcc без jvm не будет давать более оптимальный, быстрый и защещённый от утечек памяти код?

>По мне - всё, что не даёт на выходе хорошо оптимизированный по скорости и размеру машинный код - интерпретатор.

А по-мне - любой, кто путает общепринятую терминологию - полный идиот.

>Виртуальная машина - это просто разновидность интерпретатора.

Новое поколение клоунов выросло?

>С выходом MS JVM, если не ошибаюсь, в 1997 году Java перестал быть интерпретатором.

Java никогда не была интерпретатором. Отродясь. Не путайте её с JavaScript.

>Нет, я ещё понимаю тормозов, которые PHP или Perl называют интерпретаторами, но называть таковым Java - это просто элементарное незнание отличий интерпретаторов

А может это не они тормоза, а Вы такой акселерат? В случае Java имеет место быть обыкновенная интерпретация, несмотря на тот факт, что имеется программа-компилятор, переводящая исходный текст на java в байт-код JVM. Этот байт-код не может быть выполнен напрямую процессором машины (за исключением некоторых встраиваемых систем, где JVM может быть реализована аппаратно), поэтому он ИНТЕРПРЕТИРУЕТСЯ виртуальной машиной Java перед тем как попасть в исполнительные механизмы процессора (устройство управления, АЛУ etc)

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

Вот я и говорю - вопрос глубоко неверный. Нету никакой трагедии! Питон компилируется в байт-код явы со всеми вытекающими (если надо) или остается скриптовым языком (ради чего все возможно и затевалось!).

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

>А может это не они тормоза, а Вы такой акселерат? В случае Java имеет место быть обыкновенная интерпретация, несмотря на тот факт, что имеется программа-компилятор, переводящая исходный текст на java в байт-код JVM. Этот байт-код не может быть выполнен напрямую процессором машины (за исключением некоторых встраиваемых систем, где JVM может быть реализована аппаратно), поэтому он ИНТЕРПРЕТИРУЕТСЯ виртуальной машиной Java перед тем как попасть в исполнительные механизмы процессора (устройство управления, АЛУ etc)

Полностью согласен.

И вообще: подмена понятий в соверменной IT-шной сфере на РУССКОМ и любом другом кроме АНГЛИЙСКОГОГО языка - дело привычное, а скорее это подмена терминов, но многие как-то справляются, потому что знают суть - природу объектов и понятий. А терминологией обычно увлекаются те ортодоксальные мудаки, которые до сих пор воспринимают и обрабатывают действительность, заглядывая в студенческую тетрадь, кстати, не лучшего в таком случае учебного заведения.

> В случае Java имеет место быть обыкновенная интерпретация,

Вы похоже, аггресивнный неуч, уверенный в том что его вопиющая беграмотность - вершина просветления. Сейчас вам общественность скажет, где искать стену. Советую готовится к разбегу. Для более точного попадания распечатайте и прикрепите к стене вот этот скажем текстик:

http://java.sun.com/developer/onlineTraining/Programming/JDCBook/perf2.html

>Вот я и говорю - вопрос глубоко неверный. Нету никакой трагедии! Питон компилируется в байт-код явы со всеми вытекающими (если надо) или остается скриптовым языком (ради чего все возможно и затевалось!).

Еще раз. Иными словами, он спрашивает, почему скрипт на питоне в одном случае можно исполнить на питоновском интерпретаторе, а в другом случае его же на джавовской ВМ - в чем разница?! Я лично догадываюсь в чем разница: :) джавовская ВМ может быть на некоторых задачах работает быстрее питона.

> Полностью согласен.

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

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

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

>Поздравьте себя, вы тоже были в анабиозе 10 лет. Может быть перед тем как называть мудаками всех тех, кто не попал в криогененую камеру, стоило почитать немного документации?

Скажите на милость, почему вы не хотите понимать элементарных вещей: мне насрать на разницу между интерпретатором как понятием и виртуальной машиной как понятием. Для меня важно только одно - что я буду запускать? 1) anyname.exe? 2) java anyname.jav? 3) python anyname.py?

2 и 3 варианты - это ИНТЕРПРЕТАЦИЯ файлов anyname.jav & anyname.py, 1 - это компиляция. Все! Мне пох в чем механически различаются процессы интерпретации 2 и 3 и как это называется у ортодоксов. :)

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

Теперь я могу рассчитывать, что говорю с профессионалом. Спасибо :)

Снова эти глупые споры. JavaScript - интерпретируемый язык. Если загрузить кусок кода JS в память и установить на него Instruction Pointer, то процессор конечно же ничего не исполнит (разумного), ибо нужна программа-интерпретатор, которая бы интерпретировала код на JS в правильные инструкции процессора (например x86). Далее, берем байт-код Java и проделываем то же самое, будет ли работать? Нет, потому что, опять же нужен интерпретатор, который бы транслировал этот байт-код в инструкции, в данном случае им является виртуальная машина JVM. Берем код, сгенеренный gcc, устанавливаем на него указатель инструкции - и, о чудо, работает:) Потому что gcc - это компилятор, он отработал один раз и на выходе у него x86 инструкции, которые могут быть выполнены непосредственно процессором, без интерпретации. В Java есть компилятор, но это всего лишь ПРОМЕЖУТОЧНЫЙ ЭТАП, по природе же своей эта среда конечно же интерпретирующая. Многие почему-то думают, что есть только 2 вещи - компилятор и интерпретатор, и ничего между ними не существует. Интерпретатор "просто читает код и его выполняет", а компилятор "дает на выходе какой-то двоичный файл". Это все так, только такое рассуждение достойно разве что школьного учебника информатики

>Виртуальная машина - это просто разновидность интерпретатора.

Тогда и CPU -- интертрепатор :)

> Для меня важно только одно - что я буду запускать? 1) anyname.exe? 2) java anyname.jav? 3) python anyname.py? 2 и 3 варианты - это ИНТЕРПРЕТАЦИЯ файлов anyname.jav & anyname.py, 1 - это компиляция.

Для начала стоит подумать, что один и тот же файл clr_sample.exe запускается:

1) в винде как clr_sample.exe

2) в винже же как mono clr_sample.exe

3) в линуксе как mono clr_sample.exe

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

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

>Многие почему-то думают, что есть только 2 вещи...

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

> Это эпидемия.

Это JOPA ! Полная JOPPA !

скоро придет всем большая JavaJopa !

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

Флейм уже... см предыдущий пост, мы просто говорим о разных вещах, или, точнее, о разных уровнях одного и того же предмета. 1) я уточняю умозаключение: есть разница в том как запустить исходник в процесс преобразования его в результат исполнения. 2) я говорю именно об этой разнице - о разнице запуска интерпретируемого исходника и скомпилированного файла. 3) мои представления о самом процессе преобразования исходника в результат исполнения - действительно на уровне, но может быть не шестого класса, а скажем 10 :) Впрочем, об этом процессе мне большего знать и не надо, равно как и о том, почему нет жизни на марсе.

> Тогда и CPU -- интертрепатор

странно, что многие этого не понимают. Машкод - это не последняя стадия интерпретации.

>> Тогда и CPU -- интертрепатор > странно, что многие этого не понимают. Машкод - это не последняя стадия интерпретации.

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

>Тогда и CPU -- интертрепатор :)

А что Вы смеетесь? Именно так оно и есть, с тех пор как Уилкс в 1951 году выпустил работу по микропрограммированию, большинство процессоров именно так и делается (первая широко распространенная была, кажется IBM S/360). В современных процессорах машинные инструкции не выполняются напрямую при помощи жесткой комбинационной логики, а имеется интерпретатор (аппаратный) и память микропрограмм. Каждой машинной инструкции соответствует своя микропрограмма, выполняя которую интерпретатор выполняет собственно машинную команду

> Далее, берем байт-код Java и проделываем то же самое, будет ли работать?

Неправильно. Берём из кэша JIT-скомпилированный машинный код, соответствующий коду Java - и всё прекрасно работает.

"Many interpreted languages are first compiled to some form of virtual machine code, which is then either interpreted or compiled at runtime to native code."

http://en.wikipedia.org/wiki/Interpreted_language#Languages_usually_compiled_...

>Неправильно. Берём из кэша JIT-скомпилированный машинный код, соответствующий коду Java - и всё прекрасно работает.

Неправильно. И название "Just-in-time COMPILER" еще раз доказывает, что грань между компиляцией и интерпретацией не такая резкая, как думают некоторые, которым в голову намертво втемяшились школьные уроки информатики. Компилятор в java есть, с этим никто не спорит: это программа, транслирующая исходный текст на ЯЗЫКЕ ПРОГРАММИРОВАНИЯ JAVA (высоуровневый ООП-язык) в байт-код. Все, на этом работа компилятора закончена, далее полученный байт-код ИНТЕРПРЕТИРУЕТСЯ конкретной JVM, под конкретную архитектуру и конкретную ОС. И машинный код в кэше - результат не компиляции, а интерпретации. А то, что в названии есть слово сompiler ничего не говорит, много воды утекло за прошедшие 60 лет, когда были придуманы 2 этих понятия, изначально явно раличных. Для того, чтобы процессор хоть что-то исполнил ему нужны "родные" инструкции и никакому интерпретатору от этого не деться. Различаются только особенности реализации, но тот же JavaScript-интерпретатор в конце-концов должен предоставить процессору машинный код. Интерпретировать в "чистом" виде можно разве что код на ассемблере, там в принципе можно представить себе интерпретатор в виде простого анализатора строчек и кучу if'ов или switch'ей анализирующих эти строчки и выполняющие их. Но тот же интерпретатор javascipt устроен гораздо сложнее. Еще раз: компилятор - это программа, транслирующая код ЯЗЫКА ПРОГРАММИРОВАНИЯ в МАШИННЫЙ КОД. JIT compiler компилятором не является, поскольку на входе у него уже машинные инструкции JVM, которые языком программирования не являются. Не согласны? Тогда давайте Ваше определение интерпретатора и компилятора

"интерпретация" и "скриптовый язык" видите разницу?

ИНТЕРПРЕТАЦИЯ (лат. interpretatio) - 1) в широком смысле - истолкование, объяснение, перевод на более понятный язык...

P.S. Еще раз повторюсь - мое мнение такое: не только компиляторами и интерпретаторами жив человек:) Есть и промежуточные варианты. JIT в чистом виде не является интерпретатором (потому что на выходе дает native-машинный код), ну и компилятором в чистом виде его назвать нельзя. Истина где-то посередине, просто не все признают саму возможность существования это середины

anonymous> иди и убейся, exe он тут запускает

да,да иди и убейса ап стену, не срамис, хотя дело говоришь

>>Виртуальная машина - это просто разновидность интерпретатора.

>Новое поколение клоунов выросло?

Уважаемый, твое поколение новее моего

дело не в том, что он даёт на выходе, а в том что он получает на входе

> Java никогда не была интерпретатором. Отродясь.

Цитата из Вики: "The first implementations of the language used an interpreted virtual machine".

В JVM 1.0 не было JIT, она была чистым интерпретатором. То, что она интерпретировала байткод, а не текст, не меняет ее интерпретаторной сущности. Если верить Вики, первый JIT в Сановской JVM появился в версии 1.2.

Интересно, хватит ли у представителя поколения "неклоунов" духа признать ошибку? :)

http://en.wikipedia.org/wiki/Java_version_history http://en.wikipedia.org/wiki/Java_(programming_language)

да на самом деле все эти jython'ы, jruby и иже с ними просто семечки. Вот PyPy - это сила... да.

Судя по тому, что я читал про микрософтовский .NET,

он компилируется 2 раза.

1й раз на этапе сборки в байткод. на любом компе.

2й раз на этапе запуска.

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

>> JIT compiler компилятором не является, поскольку на входе у него уже машинные инструкции JVM, которые языком программирования не являются. Не согласны?

С таким же успехом можно сказать, что ассемблер - не язык программирования, потому, что является набором машинных инструкций. На жававском байткоде можно писать программы (мак же как и на CLI), или будем спорить? JIT их компилирует в машинный код, что непонятно то? В результате работы JIT в памяти лежит не байткод а машинные иснтрукции, в результате работы инетрпретатора питона или жаваскрипт ничего подобного не происходит. Разница чувствуется или нет пока?

>В случае Java имеет место быть обыкновенная интерпретация

Вы просто не знаете, что этот термин обозначает. Как тут уже кто-то говорил, в таком случае процессор - интерпретатор машинного кода.

В общем, рекомендую ознакомиться с терминологией перед тем, как бездумно её использовать. Не демонстрируйте так явно свою техническую безграмотность.

>Поздравьте себя, вы тоже были в анабиозе 10 лет.

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

>мне насрать на разницу между интерпретатором как понятием и виртуальной машиной как понятием.

А нам насрать на Вашу агрессивную безграмотность и полное незнание предмета :D

>1) anyname.exe? 2) java anyname.jav? 3) python anyname.py?

Однако, виндузятник - это диагноз :D

>2 и 3 варианты - это ИНТЕРПРЕТАЦИЯ файлов anyname.jav & anyname.py, 1 - это компиляция

Кстати, налицо ещё ПОЛНОЕ незнание ничего про Java :D Человек на полном серьёзе считает, что JVM выполняет *.java? Это уже диагноз :D А всё туда же, спорить о терминах :D

> Судя по тому, что я читал про микрософтовский .NET,

Я мало знаю о .NET, и не говорил о ней :)

> .NET VM не "интерпретирует" байткод

Возможно... У меня сейчас нет настроения на терминологический флейм, поэтому я выскажу свое ХО без всяких претензий: термин "виртуальная машина" в области реализаций ЯП четко определился к началу 80-х и означал спецификацию абстрактной машины и программый _интерпретатор_ ее команд - до сих пор большинство виртуальных машин таковы. JVM и .NET VM являются исключеними - в них встроен еще и транслятор машкода одной архитектуры (VM) в другую (реальной машины). Однако (внимательно следим за руками) этот _транслятор_ объявляется _виртуальной машиной_. ИМХО, мы имеем дело с путаницей терминов, порожденной маркетинговыми требованиями.

>Если загрузить кусок кода JS в память и установить на него Instruction Pointer, то процессор конечно же ничего не исполнит (разумного), ибо нужна программа-интерпретатор

Гы. Это в ЛОР-квотес нужно. Человек путает компиляцию и трансляцию в нативный код. Действительно, выросло Windows-поколение.

А мсье хоть когда-нибудь слышал про Java-процессоры, которые исполняют байткод Явы нативно? О сколько ещё его открытий ждёт... десяти- и двадцати-летней давности. А уже современные процессы просто взорвут его мозг :D

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

>А что Вы смеетесь?

Потому что Вы не знаете общепринятых определений компилятора и транслятора.

В общем, не поленюсь пометать бисер разок...

В общем, если Вы никогда не занимались концепциями языков программирования, то запомните, что интерпретатор - это транслятор, исполняющий исходную программу "с листа", читая голый текст токен за токеном и тут же её исполняющий. Вы можете на ходу поменять исходник - и, если не произойдёт срыв указателя строк, то программа будет исполнять уже изменённый текст. Такими интерпретаторами являются классический Бейсик (скажем, у MS - qbasic, но не qb!), JavaScript, всевозможные *zh и BAT-интерпретатор в MS-DOS. Ну и множество скриптовых языков было интерпретаторами по своему рождению.

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

Есть языки смешанные. Скажем, Форт способен работать как в режиме интерпретации (скажем, компиляция программы в нём - это штатная работа интерпретатора), так и в режиме компилятора (исполнение оттранслированного кода).

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

>И название "Just-in-time COMPILER" еще раз доказывает, что грань между компиляцией и интерпретацией не такая резкая, как думают некоторые, которым в голову намертво втемяшились школьные уроки информатики.

Эта грань не такая резкая только в воспалённом мозгу некоторых неучей. Ибо все современные интерпретаторы и компиляторы различаются предельно чётко. Из древних "нечётких" разве что только Focal вспоминается, программу которого можно условно считать почти байткодом :D Шутка, конечно, но в каждой шутке...

>Цитата из Вики: "The first implementations of the language used an interpreted virtual machine".

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