Я понимаю различия между интерпретируемыми и скомпилированными языками, но если кто-то может привести некоторые примеры ситуаций, когда можно использовать интерпретированные языки поверх скомпилированных языков, а также ситуаций, когда можно использовать компилированные языки поверх интерпретируемых языков, это быть действительно полезным.
Ответы:
Насколько мне известно, нет такой вещи, как интерпретируемый «язык» или скомпилированный «язык».
Языки определяют синтаксис и значение ключевых слов кода, потоковых конструкций и различных других вещей, но я не знаю ни одного языка, который бы указывал, должен ли он быть скомпилирован или интерпретирован в спецификации языка.
Теперь, если вы задаетесь вопросом, когда вы используете языковой компилятор против языкового интерпретатора, это действительно сводится к плюсам / минусам компилятора в сравнении с интерпретатором и целью проекта.
Например, вы можете использовать компилятор JRuby для более легкой интеграции с библиотеками Java вместо интерпретатора ruby MRI. Вероятно, есть также причины использовать интерпретатор MRI ruby над JRuby, хотя я не знаком с языком и не могу говорить с этим.
Предлагаемые преимущества переводчиков:
Предлагаемые преимущества компиляторов:
Тем не менее, я бы поспорил, что в 90% случаев это выглядит примерно так : я хочу написать это программное обеспечение в blub, потому что я хорошо его знаю и оно должно хорошо работать. Я буду использовать интерпретатор blub (или компилятор), потому что это общепринятый канонический метод написания программного обеспечения в blub.
Таким образом, TL; DR - это, в основном, индивидуальное сравнение интерпретаторов и компиляторов для вашего конкретного варианта использования.
Кроме того, FFI: Интерфейс внешних функций, другими словами, интерфейс для взаимодействия с другими языками. Больше чтения в википедии
Важным моментом здесь является то, что многие языковые реализации фактически делают своего рода гибрид обоих. Сегодня многие широко используемые языки работают, компилируя программу в промежуточный формат, такой как байт-код, и затем выполняя его в интерпретаторе. Вот как обычно реализуются Java, C #, Python, Ruby и Lua. На самом деле, возможно, именно так реализовано большинство языков, используемых сегодня. Фактически язык сегодня интерпретирует и компилирует свой код. Некоторые из этих языков имеют дополнительный JIT-компилятор для преобразования байт-кода в собственный код для выполнения.
На мой взгляд, нам следует перестать говорить о интерпретируемых и скомпилированных языках, потому что они больше не являются полезными категориями для различения сложностей современных языковых реализаций.
Когда вы спрашиваете о достоинствах интерпретируемых и компилируемых языков, вы, вероятно, имеете в виду что-то еще. Вы можете спросить о достоинствах статической / динамической типизации, преимуществах распространения собственных исполняемых файлов, относительных преимуществ компиляции JIT и AOT. Это все проблемы, которые связаны с интерпретацией / компиляцией, но это разные проблемы.
Прежде всего, язык программирования может быть как интерпретированным, так и скомпилированным. Интерпретация и компиляция - это просто методы генерации исполняемого кода из исходного кода. При использовании интерпретатора исходный код читается и интерпретируется интерпретатором, который затем выполняет код так, как он его интерпретирует. Компилятор, с другой стороны, читает исходный код и генерирует исполняемый двоичный файл из исходного кода, так что программа может запускаться как отдельный процесс независимо.
Теперь, прежде чем кому-то интересно ... Да, C / C ++ / C # / Java можно интерпретировать, и да, скрипты JavaScript и Bash можно компилировать. Есть ли рабочие интерпретаторы или компиляторы для этих языков - другой вопрос.
Теперь, чтобы фактически ответить на вопрос, когда мы будем использовать «интерпретируемый язык» вместо «скомпилированного языка». Сам вопрос несколько сбивает с толку, но я предполагаю, что это означает, когда следует предпочесть интерпретацию компиляции. Одним из недостатков компиляции является то, что она генерирует некоторые издержки из-за процесса компиляции - исходный код должен быть скомпилирован в исполняемый машинный код, поэтому он не подходит для задач, которые требуют минимальной задержки при вызове исходного кода для выполнения программы. С другой стороны, скомпилированный исходный код почти всегда быстрее, чем эквивалентный интерпретируемый исходный код, из-за накладных расходов, вызванных интерпретацией кода. Переводчики, с другой стороны, могут вызывать и запускать исходный код с очень небольшими накладными расходами, но за счет производительности во время выполнения.
В конце концов, почти невозможно упомянуть какие-либо конкретные случаи использования, когда нужно отдавать предпочтение одному за другим, но, например, один (на мой взгляд, очень нереальный) случай, когда исходный код программы динамически изменяется между вызовами программы и накладные расходы на компиляцию слишком велики. высоко для того, чтобы быть жизнеспособным выбором. В этом случае интерпретация исходного кода вместо компиляции, вероятно, была бы желательна.
Тем не менее, есть нечто, что можно рассматривать как реальный пример: исходный код hidnig после развертывания. С роднойСкомпилированный код разработчик развертывает исполняемым программным кодом Macine и данными. При интерпретированном коде должен быть развернут сам исходный код, который затем может быть проверен и подвергнут повторному проектированию с гораздо меньшими усилиями, чем то, что требуется для обратного инжиниринга собственного машинного кода. Единственным исключением из этого являются такие языки, как C # и Java, которые компилируются в непосредственный язык / байт-код (MSIL для C # и Java-байт-код для Java), который затем развертывается и компилируется «вовремя» во время выполнения, что-то вроде интерпретатора. Однако существуют так называемые декомпиляторы для MSIL и Java Bytecode, которые могут воссоздать исходный исходный код с относительно хорошей точностью, и, таким образом, обратное проектирование таких продуктов гораздо более тривиально, чем продукты обратного проектирования, которые развернуты в собственном машинном коде.
Я могу подумать о следующих сценариях, когда вы будете использовать интерпретированный язык:
Я могу подумать о следующих сценариях, когда вы хотите скомпилировать код:
В конце концов, большой компромисс находится между производительностью (сколько строк кода вы должны написать) и производительностью (насколько быстро будет выполняться ваша программа).
Поскольку интерпретированные языки при преобразовании в информацию о ЦП имеют больше информации, они могут полагаться на рефлексию и динамическую типизацию, которые значительно повышают производительность . Другое преимущество интерпретируемых языков заключается в том, что они не зависят от платформы, если для этой платформы существует интерпретатор.
Поскольку ЦП не должен преобразовывать код языка в машинный код и запускать код одновременно, как в интерпретируемом случае, скомпилированные языки дают более быстрые программы. Кроме того, система, построенная на скомпилированном языке, является более безопасной, поскольку она может обнаруживать проблемы во время компиляции, что в основном означает, что вы видите ошибку при вводе (с современными IDE) вместо того, чтобы видеть ее только при фактическом запуске программы (конечно, , это не исправляет логические ошибки).
Зная это, интерпретируемые языки подходят для:
И скомпилированные языки подходят, когда:
Помимо причин, упомянутых другими, есть один особенно важный вариант использования для выбора специальной интерпретации по сравнению с любой формой компиляции или любым гибридным подходом.
В случае, если в качестве протокола связи используется язык программирования , и когда важна задержка ответа, имеет смысл избегать потери времени на компиляцию и любую возможную предварительную обработку.
Это относится, например, к языкам агентов или к тому, как, например, обычно используется Tcl / Tk.
Другая возможная причина придерживаться интерпретации - это когда языковой интерпретатор используется для самозагрузки или более сложного языка более высокого уровня, и его простота важнее производительности процесса самозагрузки.
Для почти любого другого возможного варианта использования компиляция (или гибридный подход) лучше подходит.