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

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

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

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

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

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

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

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

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

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

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

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

Говорят, что Java не имеет "позднего связывания". Связано ли это с тем, что программы Java немного быстрее Python?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

время связывания n. Момент повреждения хеш-таблицы.

==> Достижения в области вычислений можно сопоставить с «запозданием привязки», которое заставляет меня думать о моей так называемой так называемой карьере в CS: золотом прошлом, сером настоящем и радужном будущем. Это моя версия оптимизма Synge: трава зеленее, за исключением t = 0. В EDSAC I мои функции (5-канальные подпрограммы с бумажной лентой) перфорировались, склеивались и связывались примерно за две недели до ввода. Это известно как преждевременное связывание и требует ловкости с эластичными лентами. Затем появился FORTRAN с новым типом привязки: мокрые колоды карт, которые отказывались тасовать. Затем с помощью Algol и C я наслаждался статическим связыванием (во время компиляции), пока C ++ не принес ошеломляющие радости динамического связывания (во время выполнения). Мое текущее исследование направлено на то, чтобы отложить привязку до тех пор, пока не будет выполнено.Я называю это связывание последнего времени, как предсказано в Евангелии от Матфея: «... и что свяжешь на земле, то будет связано на небесах ...» (Матфея 16:19 KJV).