>даёт интервью и рассказывает одновременно дядя мутант?

>"возвращения долгов" O_o

>Google - это ядро я всегда это знал

Пунктуация - вообще в полной опе...

Самая большая БД от Google.

Ждём новости: "Самая большая в мире БД от Google."

Ещё один вылез. Закопайся.

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

RTFM на тему компиляторов и интерпретаторов.

А, вообще, в FAQ нужно. Каждые два месяца появляется очередная парочка, начинающая доказывать, что Java, Python или PHP - интерпретаторы. И не понимающие, что даже Си++ может быть интерпретатором как язык, и любой бинарник в машкодах сегодня интерпретируется на x86-процессорах.

И? Мы должны им за это в ножки поклониться?

Как это?.. Я читал, что интерпретатор - это _программа_, которая выполняет код на некотором промежуточном языке (ПОЛИЗ к примеру).

Что значит "компилирующий язык"?

http://docs.python.org/tut/node8.html#SECTION008130000000000000000

>A program doesn't run any faster when it is read from a .pyc or .pyo file than when it is read from a .py file; the only thing that's faster about .pyc or .pyo files is the speed with which they are loaded.

Это значит язык, который компилирует. Что непонятно?

Интерпретатор - это транслятор, которые не делает компиляцию программы перед выполнением, а исполняет код "с листа", байт за байтом.

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

>компилирующий язык

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

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

Иначе получается глупо.

Возьмём Си++ на ZX-Spectrum. Скомпилируем программу. Но исполним её не на родном Z80, а на эмуляторе под x86. Код будет интерпретироваться. От этого Си++ стал интерпретатором? :)

Именно. Почитай и попробуй понять, о чём там речь :)

Особенно что-нибудь вроде «Normally, you don't need to do anything to create the spam.pyc file. Whenever spam.py is successfully compiled, an attempt is made to write the compiled version to spam.pyc.»

Что за каша? Язык не имеет никакого отношения к его интерпретации.

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

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

>где объект в теле цикла может измениться "на лету". и как в этом случае избежать интерпретации?

В Java можно прямо кусок кода налету изменить. Java - интерпретатор?

В Форте можно на ходу код менять - Форт - интерпретатор (на самом деле - да, но не в этом контексте)?

Я на ассемблере писал массу самомодифицирующихся программ, в т.ч. с изменениями с исходников. Ассемблер - интерпретатор?

:D

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

...

Я зайду от противного.

Дай своё строгое определение, что такое компилятор и что такое интерпретатор.

Как он это делает. Интерпретирующе или компилирующе?

>и интерпретирует уже его.

Я там написал, почему реализация VM - это другой вопрос.

Правильно. Я не раз подчёркиваю (учись читать), что речь идёт не о языках, а о реализациях. Есть, скажем, чистые интерпретаторы Си++.

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

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

>Интерпретатор - это программа, которая исполняет код без его преобразования.

Именно так. И поэтому интерпретаторов сегодня очень и очень мало. навскидку можно назвать bash. Или многие реализации JavaScript. Ещё древний qbasic (не путать с qb - этот был уже компилятором... из-за чего, кстати, и работал сразу в десятки раз быстрее :))

Сперва ответь мне, GIL относится к виртуальной машине Питона или к транслятору исходного кода? :) Почитай, что я писал про транслятор Питона. И про его виртуальную машину.

...

Вот же каша у людей в голове :D

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

И все-таки Python - это интерпретатор.

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

>Именно так. И поэтому интерпретаторов сегодня очень и очень мало. навскидку можно назвать bash. Или многие реализации JavaScript. Ещё древний qbasic (не путать с qb - этот был уже компилятором... из-за чего, кстати, и работал сразу в десятки раз быстрее :))

Не все диалекты Лиспа поддерживают компиляцию...

Если мы по аналогии с Java-процессорами сделаем Python-процессор, то Python волшебным образом превратится в тыкв^W компилятор? :D

А если я запускаю D-программу в режиме -run - то D превращается в интерпретатор?

А если напишу баш-скрипт в две строки, который при указании ему в качестве параметра .cpp-программы скомпилирует её во временный файл и запустит его, а потом грохнет временный бинарник, то и Си++ станет интерпретатором?

...

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

Да. Но когда человек говорит, что Python - это то, или другое, то обычно по дефолту подразумевается, что говорит он только об известном ему CPython от Гвидо. Так что тут я возмущаться не стал :)

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

>Это значит язык, который компилирует. Что непонятно?

язык, наверно, все же, компилируемый.

Has the open-sourcing of Java changed anything for you?

если в руби 1.8 не было байт-кода, а в 1.9 он появился, ТО по твоим словам 1.8 - интерпретатор, а 1.9 - компилятор?

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

- Гвидо может не задаваться вообще вопросами терминологии.

- Гвидо может отождествлять для себя Питон больше с виртуальной машиной, чем с транслятором исходного кода.

- Гвидо может быть конформистом и просто старается избежать лишних нападок от людей, считающих компиляторами только компиляторы в машинный код :)

- Наконец, Гвидо может просто ошибаться :)

Если мы смотрим на язык со стороны исходного кода программы - то язык компилируемый. Если со стороны транслятора - то компилирующий :) Поскольку для одного и того же языка трансляторы могут быть разными, как компилирующими, так и интерпретирующими, то чисто лингвистически правильнее смотреть со стороны транслятора, а не исходного кода :) Исходный код могут как скомпилировать, так и интерпретировать. Тогда он будет то компилируемым, то интерпретируемым :) Неоднозначность...

Как раз поэтому разумно считать CPython компилирующим интерпретатором. Потому что интерпрератор в чистом виде в живом виде практически не встречается, а вот разница между C++ и Java, таки есть, и вполне концептуальная, и это сто́ит различать. Мешать в одну кучу Basic и Python глупо, но и мешать C++ и Java-у не менее глупо.

Да. Поэтому я подчёркиваю, что нельзя оценивать язык, нужно оценивать реализацию.

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

...

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

Язык - не компилирует!!!

> - Гвидо может [...]

> - Гвидо может [...]

В конце концов, Гвидо может быть и прав :D

Единственное, что разумно - это считать его компилирующим языком с интерпретирующей средой исполнения :)

>Потому что интерпрератор в чистом виде в живом виде практически не встречается

То, что на Земле мало индейцев и много китайцев, не повод считать китайцев с длинными тёмными волосами индейцами :)

>а вот разница между C++ и Java, таки есть, и вполне концептуальная

В чём? На уровне языков, а не реализаций. Мне даже интересно :) Вот, например, возьмём Managed C++, который генерирует .NET-байткод для исполнения потом под виртуальной машиной - чем он концептуально отличается от Java? :)

>Мешать в одну кучу Basic и Python глупо

Правильно, ибо даже qbasic и qb мешать в одну кучу глупо :D