LINUX.ORG.RU

Интерпретация vs компиляция

 ,


0

3

Существует мнение, что интерпретируемый язык гораздо мощней компилируемого. Я много думал, над этим, над сутью этого явления.

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

Тогда, что же делает интерпретируемые языки мощными?

Похоже, остается только один вариант: eval, явный исполнитель на уровне языка. Преимущество тут в том, что рантайм эвала имеет доступ (не во всяком ЯП, не всегда, но если) ко всему текущему окружению. Получается тут, кажется, эффект отражения. Иными словами, мы способны находится, как-бы, «и тут и там» одновременно, в то время как в случае компилируемого языка, мы либо тут либо там.

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

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

Ответ на: комментарий от energyclab

То, о чем ты говоришь, с точки зрения семантики не имеет никакого значения. Просто один текст перезаписывается в другой, вот и все.

terminator-101
() автор топика
Ответ на: комментарий от terminator-101

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

energyclab
()
Ответ на: комментарий от energyclab

Четкой границы нет, так как в пороки можно вдаваться все глубже и глубже
преобразовывается

Похоже, кстати, что за википедию активно взялись первоклассники.

В общем случае, любой язык может быть компилируемым и интерпретируемым,

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

terminator-101
() автор топика
Ответ на: комментарий от energyclab

Все перечисленные — компилируемые языки

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

Вот поэтому я и пишу, что Python — компилируемый (а не интерпретируемый) язык. Да, ВМ в Python преимущественно интерпретируемая, но вопрос звучал о языке, а не ВМ.

А в JVM и .NET — и виртуальные машины компилируемые.

Не из-за этого ли процесса принято называть такие языки интерпретируемыми?

Никто вменяемый не называет даже Python интерпретируемым. А уже называть интерпретируемой Java или C# даже совсем в бредовом состоянии никто не станет :)

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

Нет. Интерпретаторы, типа bash исполняют токен за токеном именно с исходника. Что потом происходит дальше — уже не важно. Потому что интерпретация именно на этом этапе.

Есть очень древнее и очень действенная оценка, отличающая интерпретатор от компилятора. Цикл. Тело цикла интерпретатор транслирует на каждой итерации. Компилятор только один раз, при компиляции.

KRoN73 ★★★★★
()
Ответ на: комментарий от energyclab

Только вот «скомпилированный» скрипт на питоне я не смогу запустить на другой машине, без интерпретатора

Создай аппаратную Python-машину (как в случае Java и Java-процессоров или Forth и Forth-процессоров) и сможешь исполнить его байткод на железе. Я же писал выше, что это как раз та фишка, которая из определений интерпретатора или компилятора требует выкинуть отсылку на машинный код. Ибо это нечёткое понятие. И код x86 при исполнении на ARM требует наличия виртуальной машины — тогда что, GCC нужно считать интерпретатором? :D

KRoN73 ★★★★★
()
Ответ на: комментарий от energyclab

При условии той же версии линкуемых библиотек и пр.

Емнип был интерпретатор для С. И ничего не мешает сделать компилятор для питона, они даже есть только с урезанной функциональностью.

AIv ★★★★★
()
Последнее исправление: AIv (всего исправлений: 1)
Ответ на: комментарий от energyclab

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

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

terminator-101
() автор топика
Ответ на: комментарий от KRoN73

Статья на вики как никак все расписывает по своим местам...В Python, Java и .NET инструкции программы выполняются специальной программой, а не процессором, именно поэтому они скорее интерпретируемые языки (точнее не .NET а C#) чем компилируемые...

Цикл. Тело цикла интерпретатор транслирует на каждой итерации

C этим я согласен, как говорится step-by-step.

energyclab
()
Ответ на: комментарий от terminator-101

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

energyclab
()
Ответ на: комментарий от energyclab

В Python, Java и .NET инструкции программы выполняются специальной программой, а не процессором

Я не зря делал отсылку к Java-процессорам.

И не зря делал отсылку к исполнению кода, созданного GCC под x86 «специальной программой» виртуальной машины под ARM или PowerPC.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Я этот коммент что то пропустил...

Создай аппаратную Python-машину

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

GCC нужно считать интерпретатором? :D

не стоит провоцировать на написание определений... ибо это к топику не относится...но смешно получилось

energyclab
()
Ответ на: комментарий от energyclab

и я еще раз повторяю, нету четкой границы между этими понятиями

Конечно. В рамках нечётких определений (в т.ч. фигурирующих такими абстрактными и нечёткими понятиями, как «машинный код») нет и границы чёткой.

А с нормальным определением и границы все строгие.

KRoN73 ★★★★★
()
Ответ на: комментарий от hateyoufeel

у меня бомбануло когда я первый раз скомпилил и нажал ls -l

Progressive
()
Ответ на: комментарий от Eddy_Em

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

Aswed ★★★★★
()

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

Aswed ★★★★★
()
Ответ на: комментарий от Aswed

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

anonymous
()
Ответ на: комментарий от anonymous

Тем-более, что хаскелист Вася уже заканчивает разработку продвинутого счетчика факториалов

нормальные люди считают факториал только в компайл-тайм C++ ! Даже если нужен рантайм, программа генерит С++ код с шаблонами и компилирует его. Гарантирую это

Progressive
()
Ответ на: комментарий от energyclab

ну что за бред

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

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

Stil ★★★★★
()
Ответ на: комментарий от KRoN73

А сколько там софтовых уровней абстракции под этим самым «машинным кодом» (который гцц ваяет), прежде чем дело дойдет до суровых триггеров?;-)

AIv ★★★★★
()
Ответ на: ну что за бред от Stil

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

Да легко. Мой народ изобрёл кросскомпиляцию для таких случаев.

hateyoufeel ★★★★★
()
Ответ на: комментарий от AIv

А сколько там софтовых уровней абстракции под этим самым «машинным кодом»

Так я как раз в теме уже писал об этом — Интерпретация vs компиляция (комментарий) — там как раз сперва много интерпретации проходит, пока до управления железом дойдёт :)

KRoN73 ★★★★★
()
Ответ на: комментарий от hateyoufeel

ну очевидно же, что я имел в виду запуск ELF 64-bit LSB executable, x86-64, а не кросскомпилированный бинарь

Stil ★★★★★
()
Ответ на: комментарий от Stil

ну очевидно же, что я имел в виду запуск ELF 64-bit LSB executable, x86-64, а не кросскомпилированный бинарь

Очевидно кому?

Да, тут можно ещё FatELF заюзать. Даже в этом случае бинарник будет меньше размером, чем интерпретатор с кучей модулей.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Aswed

компиляция - код из одного языка перегоняется в другой

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

energyclab
()
Ответ на: комментарий от hateyoufeel

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

Stil ★★★★★
()
Последнее исправление: Stil (всего исправлений: 1)

буду краток: лишь бы работало, причем достаточно для задачи быстро - вот и всё, как ты это ни называй! :)

I-Love-Microsoft ★★★★★
()

Чеет я не понял, а что ты такого можешь сделать со своим эвалом, чего я не могу сделать в каком нибудь c# с его доступом к ast?

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

Может, не совсем по-теме, но вот, один чувак приводит вот такой код на newlisp, в качестве proof of concept



(define infinit-loop (lambda() (while true 1)))

(define-macro (at-least-two)
  (let (c) ; счетчик 
    (doargs (i (= c 2)) ; если счетчик =2 выходим из цикла
    (println i) ; проверяем ленивость (пока итерируем будет печатать)
      (if (eval i)
  (inc c))) ; инкремент
  (>= c 2))) ; возвращаем


(println (at-least-two 
(= 2 4)
(= 1 1)
(= 2 2) ; тут выходим
(= 3 2)
(infinit-loop)
(= 2 5)
(= 2 20)))

; output:

;  (= 2 4)
;  (= 1 1)
;  (= 2 2)
;  true
  


Суть алгоритма такова. на вход ф-ции подается произвольное количество выражений. Они вычисляются только внутри функции (подобно ленивому if, до бесконечного цикла, как видно из примера, не доходим), с помощъю eval. если выражение возвращает истину, срабатывает инкремент счетчика. Если счетчик =2 выходим из цикла. Возвращаем результат (>= i 2). Цель — проверить есть ли среди аргументов хотя бы два выражения возвращающих истину, не тратя ресурсов на лишние проверки.

terminator-101
() автор топика

забаньте уже этого клоуна

reprimand ★★★★★
()
Ответ на: комментарий от energyclab

В Python, Java и .NET инструкции программы выполняются специальной программой, а не процессором

1) Java бывает разная.

2) В MSDN явно указано, что .NET никогда так не делает.

BlackHawk
()
Ответ на: комментарий от terminator-101

Но участки с eval невозможно статически проанализировать, поэтому, код с eval не оптимизируется, ЕМНИП

Где? В лиспе можно. Там собственно вообще вся программа компиляется через eval.

no-such-file ★★★★★
()
Ответ на: комментарий от Progressive

это когда hello world весит 22 Мб ?

22Мб весит hello world со встроенным компилятором.

no-such-file ★★★★★
()

Иными словами, мы способны находится, как-бы, «и тут и там» одновременно, в то время как в случае компилируемого языка, мы либо тут либо там.

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

Выразительность идет именно из-за разделения рантайм-компайлтайм, которые не могут смещиваться. У интерпретатора компайлтайма вовсе нет. То есть компилируемый ЯП может сделать в рантайме все, что может сделать интерпретируемый, но интерпретируемый не может сделать в компайлтайме ничего за отсутствием последнего.

anonymous
()
Ответ на: комментарий от energyclab

Ну так сишка тоже компилируется в байткод и потом этот байткод интерпретируется процессором. Значит сишка = питон.

anonymous
()
Ответ на: комментарий от energyclab

Почему не сможешь? Сможешь. Выполняй на аппаратном интерпретаторе питона (так же как сишку ты выполняешь на аппаратном интерпретаторе х86, например)

anonymous
()
Ответ на: комментарий от Progressive

Да, но в них входит полноценный интерпретатор, компилятор и дебаггер, например в sbcl так.

anonymous
()
Ответ на: комментарий от anonymous

На самом деле, это не макрос, а fexpr, сахар вводит в заблуждение. Задча, да, простая, можно сказать, еепросто решить, например, в тикле или джаваскрипте. Но в CL и Scheme,например, это так просто не решается.

terminator-101
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.