LINUX.ORG.RU

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

 ,


0

3

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

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

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

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

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

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

Я много думал, над этим, над сутью этого явления.

Проиграл. Универсальная фраза.

anonymous
()

У них разные области применения. Ты ничего серьезного на интерпретируемом не сделаешь. Ну, а сиюминутную хрень на компилируемом писать тоже неудобно — долго.

Eddy_Em ☆☆☆☆☆
()

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

Я не могу больше работать, я составляю различные варианты из фраз, из этих, из сути этого бреда.

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

У них разные области применения. Ты ничего серьезного на интерпретируемом не сделаешь. Ну, а сиюминутную хрень на компилируемом писать тоже неудобно — долго.

Почему это? Не согласен ни с первым, ни со вторым. Сильно зависит от сиюминутной хрени, иногда проще открыть браузер с jsfiddle/sqlfiddle/pythonsendbox и т.д. и в интерактивной консоли ввести пару команд, но мы же не о таком «сиюминутном» говорим? Чуть больше сиюминутности и 2 команды в терминал для компила и запуска - не более пары секунд.

BaBL ★★★★★
()

Тогда, что же делает интерпретируемые языки мощными?
Похоже, остается только один вариант: eval, явный исполнитель на уровне языка

Что мешает запилить eval в компилируемый язык? Например в CL есть eval.

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

Не знаю. В CL eval не имеет доступа к текущему окружению. Вероятно, проблема тут в том, что языки с полноценным эвалом компилировать практически бессмысленно, там компиляция была бы равна исполнение+исполнение.

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

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

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

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

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

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

тогда нет отличий. Преимущества интерпретируемых - eval и кроссплатформенность. Компилируемых в машинный код - скорость. Компилируемых в байткод - джава рулит лолз

Progressive
()

статика дорогое удовольствие, но более дешёвая и предсказуемая отладка и наоборот.

Ты еще спроси лучше про кипячёную воду и подогретую в чем разница и какой практический смысл...

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

Как там на каком-то космическом аппарате пофиксили баг в lisp-коде, когда он был уже черт знает где

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

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

Компилируемых в байткод - джава рулит лолз

А какая разница, с этой точки зрения, во что он компилируется? Мне кажется, что никакой разницы нет. Все равно после компиляции нет доступа к исходному коду изнутри рантайма программы.

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

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

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

http://bash.im/quote/29750

<< TuborG >> я пони

<< FIM >> обоснуйте

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

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

когда у тебя есть доступ к eval, ты сам себе интерпретатор

Progressive
()

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

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

Можно еще много чего привести, но эти наиболее важные (в частности первый). Что же касается eval, так это всего лишь возможность языка, не более (и вообще, eval использовать плохо)

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

она просто запускается на виртуальной машине

А кто мешает компилировать в байт код виртуальной машины и выполнять на любой платформе?

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

Ты ничего серьезного на интерпретируемом не сделаешь.

Особенно учитывая, что сегодня интерпретируемых языков почти нет. Bash, некоторые виды JS. Почти всё остальное — компилируемое :) (кажется, эта тема всплывает с периодичностью раз в 3 месяца в среднем)

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

интерпретируемый язык может быть мощнее - есть возможность менять программу во время выполнения

Я с таким только на Форте ещё старой блочной модели встречался.

Как там на каком-то космическом аппарате пофиксили баг в lisp-коде, когда он был уже черт знает где

Тю. Он же не сорцы лиспа на борту вёз. А бинарный код можно поправить хоть ассемблерный (чем раньше часто и занимались на практике — самомодифицирующиеся при исполнении программы в начале 1990-х были обыденностью).

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

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

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

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

В Java код в рантайме легко модифицируется. Сколько раз при разработке L2J-сервера я переписывал методы классов на лету, без перезапуска сервера :) Это совершенно штатный режим разработки.

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

сегодня интерпретируемых языков почти нет

Куда делись python, perl, make, awk, sed, sql вместе с кучкой лиспов?

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

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

От путаницы спасает только чёткое терминологическое разделение интерпретации и компиляции. Интерпретация — поэлементная трансляция во время исполнения. Компиляция — предварительная трансляция перед исполнением. Это единственное непротиворечивое определение, не дающее запутаться :)

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

Программа на PHP компилируется в байткод, который потом интерпретируется виртуальной машиной в машинный код, который потом интерпретируется процессором.

И, конечно, конкретные версии учитывать нужно. Есть, например, интерпретаторы Си :)

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

ТС, похоже, хочет стахановскими методами стать вторым на ЛОРе по общему количеству сообщений. Анонимуса, ясен пень, ему никак не обогнать. А вот меня можно. Всего-то ему нужно писать ~1300 сообщений в сутки. И под новый год он меня обгонит.

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

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

У Java, Python или .NET большие проблемы с переносимостью? ;)

KRoN73 ★★★★★
()

Шо, опять?! В прошлом треде всем ЛОР'ом не удалось даже приблизительно сформулировать разницу между компиляцией и интерпретацией, так что нечего поднимать эту тему.

Зато с вопросом о мощности ЯП дело гораздо проще. Мощность — это, как мы помним, работа в единицу времени. Работа — это количество полезных действий, порождённых кодом (например файл прочитать или картинку нарисовать). А время здесь напрямую зависит от скорости печати программиста и от качества автодополнения IDE. Вот почему статическая типизация рулит.

С другой стороны мощность — это квадрат напряжения поделённый на сопротивление. Чем мощнее ЯП, тем больше напряжения надо для питания железяки, на которой крутится код, это сейчас известно даже школьникам. А сопротивление — это показатель того, как долго потенциальный пользователь будет сопротивляться, пока вашему отделу маркетинга не удастся впарить ему ваш продукт.

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

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

Само-собой. Только если рассматривать преимущества интерпретации только с точки зрения переносимости, т.е. с точки зрения того, в какой код идет трансляция, то никаких преиумществ тут нет. К тому же, трактовать интерпретацию таким образом тоже странно, тогда java — интерпретируемый язык, получается. ИМХО, это неправильно.

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

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

Самое кривое определение :) Хотя бы из-за отсутствия строгого понятия машинного кода. Один и тот же набор бинарных инструкций может работать как на железе, так и в виртуальной машине. Так JVM-байткод может прямо исполняться на Java-процессоре, а x86 может интерпретироваться в ARM на эмуляторе. По этому определению компилятор может превратиться в интерпретатор или наборот в зависимости от того, где исполняется бинарник :D

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

Да, не стоит путать. Потому что байт-код может быть машинным кодом и наоборот :D

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

В этом сообщении был 241 символ. Если в среднем писать по 250 символов на сообщение, это будет 325 тысяч символов в сутки. При наборе с небольшой скоростью (300 символов в минуту) получаем 1083.33 минуты — всего-то 18 часов. Т.е. если просто бредогенерировать, то вполне можно еще и часа 4 в сутки на сон уделять.

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

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

Что-то у меня дежа вю, несколько раз посмотрел на дату создания треда.

Эта тема всплывает в точности 2-4 раза в год.

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

А как же пхытон?

Классический Python — это компилируемый язык с интерпретируемой ВМ. Хотя возможны варианты с частичной компиляцией и байткода (Psyco всякие и т.п.)

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

В прошлом треде всем ЛОР'ом не удалось даже приблизительно сформулировать разницу между компиляцией и интерпретацией

Я выше сформулировал единственный (и не один десяток лет назад сформулированный) непротиворечивый вариант :)

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

Так я про это и сказал, Java, Python .NET - интерпретируемые языки: а значит проблем с переносимостью не возникнет, это и есть их основное достоинство...

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

Так я про это и сказал, Java, Python .NET - интерпретируемые языки

Все перечисленные — компилируемые языки. Кроме того, Java и .NET^W C# — ещё и с компилируемой VM :)

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

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

Я понимаю, что код на Python «компилируется» в байт код, но я уже писал, что надо понимать разницу в интерпретаторе VM и процессора, и Вы сами позже об этом упомянули... Вопрос весь в том, что есть интерпретатор python, который «интерпретирует» (выполняет) байт код (в который и были скомпилированы исходники). Не из-за этого ли процесса принято называть такие языки интерпретируемыми?... И да, я понимаю, что какой-нибудь make или bash - прямой интерпретатор, однако, если мы рассмотрим процесс их работы точно так же глубоко, то выясним, что у них тоже есть внутренние представления команд...

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