Интерпретируемое, Компилируемое и позднее связывание

Чем Python отличается от другого интерпретируемого языка?

Это включает в себя расщепление волос. Интерпретируемые языки и языки "управляемого кода", такие как C# и языки виртуальных машин (например, Java), образуют странный континуум. Есть люди, которые скажут, что все языки "интерпретируются" - даже машинный язык. Ведь электронные схемы процессора "интерпретируют" машинный язык.

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

Не могли бы вы сказать мне, что означает "поздняя привязка" в контексте Python?

Переменные

Не объявляются имеющими тип. Переменная привязывается к типу как можно позже-с присвоением фактического значения. объект.

Является ли Java интерпретируемым / компилируемым языком?

Да. Он скомпилирован в байтовые коды. Байтовые коды интерпретируются. Я предпочитаю называть это интерпретацией.

Однако люди будут (по действительно неясным причинам) не соглашаться. Наличие любого вида шага" компиляции " - даже минимального-всегда сбивает людей с толку. Перевод в байтовый код практически не имеет отношения к реальному поведению программы во время выполнения. Некоторые люди любят говорить, что только языки, которые полностью свободны от какой-либо примеси предварительной обработки "компиляции", могут быть интерпретированы. Примеров этому уже не так много, поскольку многие языки переводятся с дружественного человеку текста на дружественные интерпретатору байтовые коды. Даже в Applesoft Basic (еще в 80-х годах) такой перевод выполнялся при вводе кода.

Некоторые JVM делают JIT. Некоторые-нет, некоторые-смесь. Сказать, что JVM делает только JIT-перевод байт-кода, неверно. Некоторые Для JVM делать. Некоторые-нет.

Чем он отличается от Python в плане компиляции / выполнения?

Вовсе нет. Виртуальная машина Java может выполнять Python. [Для тех, кого легко запутать, слово " python "в этом контексте не может означать"источник python". Это должно означать байт-код python.]

Говорят, что Java не имеет "поздней привязки". Имеет ли это какое-либо отношение к тому, что Java-программы слабо быстрее Python?

Возможно. Java-программы часто быстрее из-за JIT-компиляторов, которые переводят байтовый код Java в машинный код во время выполнения.

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

На самом деле существует небольшое наказание за "позднюю" привязку. Атрибуты и методы Python разрешаются с помощью простой поиск по словарю. Словарь-это хэш; производительность довольно хорошая. Хэши для имен могут быть помещены в" интернированный " пул строковых литералов, амортизирующий затраты на вычисление хэша.

Для настоящего удовольствия, посмотрите PyPy и RPython. Это интерпретатор Python, который может выполнять компиляцию JIT. В итоге вы получаете 2-х уровневый переводчик. Ваш код интерпретируется PyPy. PyPy интерпретируется RPython. http://alexgaynor.net/2010/may/15/pypy-future-python/

Существует связь между тем, что мы называем временем связывания и понятием интерпретации/компиляции.

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

Затем идет реализация языка. Тем больше информации есть статически известно заранее, тем проще написать компилятор. И наоборот, чем более поздно связан язык, тем он сложнее. Отсюда необходимость иногда полагаться на интерпретационные техники.

Однако различие между ними не является строгим. Мы можем не только считать, что все в конечном счете интерпретируется (см. ответ S. Lott), но и часть кода может быть скомпилирована, декомпилирована или перекомпилирована динамически (например, JIT), что делает различие очень нечетким.

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

Я мало что знаю о Python, но Python практикующие предпочитают, возможно, термин "поздняя привязка", чтобы избежать такой путаницы.

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

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

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

Время привязки - это когда имена разрешаются к вещам. Более динамичные языки имеют тенденцию к позднему связыванию. Это может быть отдельно от интерпретации / компиляции - например, методы objective-C разрешаются поздно и динамически по сравнению с C++. Java делает большую часть его привязки во время загрузки класса: позже, чем C, но раньше, чем питон.

Моя любимая цитата из компьютерного противоречия Стэна Келли-Бутла :

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

Успехи в вычислительной технике можно сопоставить с "запоздалостью привязки", которая заставляет меня задуматься о моей собственной так называемой карьере CS: золотое прошлое, серое настоящее и розовое будущее. Это моя версия оптимизма Сингэ: трава зеленее, за исключением t=0. На EDSAC I мои функции (5-канальные подпрограммы бумажной ленты) были пробиты, склеены и связаны примерно за две недели до ввода. Это известное связывание aspremature и требует ловкости с эластичными лентами. Следующим пришел Фортран с новым видом привязки: мокрые колоды карт, которые отказывались тасоваться. Затем с Algol и C я наслаждался статическим (во время компиляции) связыванием, пока C++ не принес ошеломляющие радости динамического (во время выполнения) связывания. Мои текущие исследования направлены на то, чтобы отложить привязку до тех пор, пока она не будет выполнена. Я называю это связыванием в конце времени, как предсказано в Евангелии от Матфея:"...и все, что ты свяжешь на Земле, будет связано на небесах...(От Матфея 16: 19).