Что такое механизм выполнения сценариев?

По сути, вы обнаружили, что различие между языком сценариев и языком "без сценариев" является довольно искусственным. Python может быть скомпилирован в байт-код JVM (с Jython), и я считаю, что Ruby также может - тогда «движком», запускающим рассматриваемый код Python или Ruby, будет JVM, тот же самый «движок», который запускает код Java (или Scala код и т. д.). Аналогично с .NET и IronPython (или IronRuby) - тогда «движком» является Microsoft CLR, как и для C #, Boo и так далее. Языки, называемые «скриптовыми», часто являются динамически типизированными ... но я никогда не слышал, чтобы этот термин использовался для других важных языков с динамической типизацией, таких как Smalltalk, Mozart / OZ или Erlang ...; -).

Я знаю, что вы приняли ответ, однако здесь есть некоторая несогласованность.

Говоря о скриптовом движке , мы обычно имеем в виду небольшой встроенный язык, который находится внутри шаблон и генерирует текстовый вывод или документы. Например, Freemarker и Velocity часто называют движками сценариев. Erb тоже мог бы сидеть здесь, но, как ни странно, его не так часто называют обработчиком сценариев.

язык сценариев обычно не требует этапа компиляции, поэтому его можно запустить проще как a или из сценария оболочки. Сюда входят такие вещи, как awk, perl, tcl, python, ruby ​​и так далее. Эти языки обычно должны быть краткими, а безопасность типов часто необязательна. Windows поддерживает несколько языков в своих средствах хоста сценариев . Это открывает доступ к языкам сценариев для различных компонентов в Windows.

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

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

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

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

Вероятно, наиболее близким к тому, о чем вы говорите, является интерпретатор :

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

В основном интерпретатор (или механизм сценариев, если вы предпочитаете) - это компонент, который отвечает за превращение сценария в машинный код во время выполнения (в отличие от компилятора, который создает машинный код до времени выполнения).

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

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

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