Какие функции интерпретируемых языков разве скомпилированный не может иметь?
Интерпретируемые языки являются обычно более высокоуровневыми и поэтому имеют функции как динамический контроль типов (включая создание новых переменных динамично без объявления), печально известное eval и много много других функций, которые делают жизнь программиста легче - но почему скомпилированные языки не могут иметь их также?
Я не имею в виду языки как Java, которые работают на VM, но те, которые компилируют в двоичный файл как C (++).
Я не собираюсь составлять список теперь, но если Вы собираетесь спросить, какие функции я имею в виду, изучите, какой PHP, Python, Ruby и т.д. должен предложить.
- Какие типичные функции интерпретируемых языков can't/don't/do существуют на скомпилированных языках? Почему?
5 ответов
Вы не могли правдоподобно выполнить eval , например, по причинам, которые, как мне казалось, были довольно очевидными: как именно вы бы это реализовали? Сделать среду выполнения полной копией компилятора? Каждый раз, когда вы хотели оценить строку (имея в виду, что каждый раз она может быть другой!), Вы должны сохранять строку в файл, запускать компилятор для создания библиотеки DLL / shared-lib, а затем загружать эту DLL / shared-lib и назвать свой код? Вы не понимаете, почему это может быть непрактично? ;)
Вы можете повсюду найти такие вещи в динамических языках, которые вы не можете сделать со статическим кодом, если не считать в основном запуска интерпретатора, по сути, за кулисами.
Продолжая от Дарио - я думаю, вы действительно спрашиваете, почему скомпилированная программа не может оценивать операторы во время выполнения (например, eval). Вот несколько причин, которые я могу придумать:
- Полный компилятор должен быть распространен вместе с программой (или быть частью программы)
- Чтобы функция eval имела доступ к информации о типах и символам (например, именам переменных и имена функций) в среде, в которой она использовалась, исходная программа должна была быть скомпилирована с доступными этими символами (скомпилированные языки обычно удаляют эти символы во время компиляции).
Изменить: Как отмечалось, ни одна из этих причин не делает невозможным для языка / компилятора возможность оценки кода во время выполнения, но это определенно вещи, которые необходимо учитывать при разработке компилятора или при разработке языка.
Компилируется ли исходный код - в родные двоичные файлы, какой-то промежуточный язык (Java Bytecode / IL) - или интерпретируется, абсолютно не является признаком языка . Это просто вопрос реализации.
Фактически у вас могут быть и компиляторы, и интерпретаторы для одного и того же языка, например
- Haskell: GHC <-> GHCI
- C: gcc <-> ch
- VB6: VS IDE <-> VB6 compiler
Определенные языковые особенности, такие как eval или динамическая типизация, могут указывать на различие между так называемыми «динамическими языками» и статическими, но как это выполняется, никогда не может быть основным вопросом.
Изначально одним из самых больших преимуществ интерпретируемых языков была отладка. Так вы можете получить невероятно точную и подробную информацию при поиске причины неработоспособности программы. Однако большинство компиляторов стали настолько совершенными, что это уже не так важно.
Другое главное преимущество (по крайней мере, на мой взгляд) заключается в том, что с интерпретируемыми языками вам не нужно ждать вечность, пока ваш проект скомпилируется, чтобы протестировать его.
Возможно, вопрос не в интерпретируемых / скомпилированных языках (компиляция в любом случае неоднозначна), а в языках, которые имеют / не содержат свой собственный компилятор с их? Например, мы сказали, что C ++ может выполнять eval с помощью удобного компилятора, плавающего в приложении, и отражение, по-видимому, в чем-то похоже.