Какие особенности интерпретируемых языков может не иметь скомпилированный?

Question

Интерпретируемые языки обычно более высокого уровня и поэтому имеют такие функции, как динамическая типизация (в том числе динамическое создание новых переменных без объявления), печально известная eval и многие другие функции, облегчающие жизнь программиста - но почему не могутони есть и у скомпилированных языков?

Я имею в виду не такие языки, как Java, которые работают на виртуальной машине, но те, которые компилируются в двоичные, такие как C (++).

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

• Какие общие возможности интерпретируемых языков могут 't / не / существуют в скомпилированных языках?Почему?

Answer 1

Независимо от того, скомпилирован ли исходный код - в собственные двоичные файлы, в какой-то промежуточный язык (Java Bytecode / IL) - или интерпретирован - это абсолютно без особенностей языка . Это просто вопрос реализации.

На самом деле вы можете иметь как компиляторы, так и интерпретаторы для одного и того же языка, например

• Haskell: GHC <-> GHCI
• C: gcc <-> ch
• VB6: VS IDE <-> VB6-компилятор

Некоторые функции языка, такие как eval или динамическая типизация, могут предполагать различие между так называемыми «динамическими языками» и статическими, но способ запуска 1011 * никогда не может быть основным вопросом.

Answer 2

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

Answer 3

Продолжая от Дарио - я думаю, что вы действительно спрашиваете, почему скомпилированная программа не может оценивать операторы во время выполнения (например, eval). Вот несколько причин, о которых я могу подумать:

• Полный компилятор должен распространяться вместе с программой (или быть частью программы)
• Чтобы функция eval имела доступ к информации о типах и символам (таким как имена переменных и имена функций) в среде, в которой она использовалась, исходная программа должна быть скомпилирована с такими доступными символами (скомпилированные языки обычно удаляют эти символы в время компиляции).

Редактировать: Как уже отмечалось, ни одна из этих причин не делает невозможным для языка / компилятора возможность оценивать код во время выполнения, но это определенно вещи, которые необходимо учитывать при разработке компилятора или при разработке языка.

Answer 4

Вы не могли бы правдоподобно сделать eval, например, по причинам, которые я считал довольно очевидными: как именно вы бы это реализовали? Сделать среду выполнения полной копией компилятора? Каждый раз, когда вы хотите оценить строку (имея в виду, что каждый раз она может отличаться!), Вы сохраняете строку в файл, запускаете на нем компилятор, чтобы создать DLL / shared-lib, а затем загружаете эту DLL / shared-lib и назовешь свой код? Вы не можете понять, почему это может быть непрактично? ;)

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

Answer 5

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

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