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

Я слышал о нескольких ситуациях, когда люди использовали, скажем, JavaScript или Python (или что-то еще) внутри программы, написанной на C #. Когда было бы лучше использовать язык, подобный JavaScript, чтобы сделать что-то в программе на C #, чем просто делать это на C #?

Если у вас есть поведение, которое вам не нужно перекомпилировать, чтобы изменить программу. Именно поэтому многие игры используют Lua в качестве языка сценариев / моддинга.

Этот метод может использоваться для реализации базовой логики, которая легко переносима между различными языковыми средами. Например, у меня есть симулятор калькулятора, где вся внутренняя логика калькулятора реализована на 100% JavaScript. Код пользовательского интерфейса, конечно, отличается для каждой платформы:

• Веб-браузер (JavaScript)
• iOS (Objective-C)
• Windows (C ++ с Qt)
• Mac OS X (C ++ с Qt)
• Java Swing (Java)

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

Очень широко есть две ситуации, когда вы примените этот шаблон:

1. Это используется внутри, чтобы использовать некоторое качество встроенного языка.
2. Это используется для обеспечения внешней программируемости.

внутренне

• Обычно интерпретируется встроенный язык, который позволяет быстро вносить и тестировать изменения без повторной компиляции.
• Встроенный язык может быть более выразительным, чем язык, на котором написано ваше основное приложение, что также позволяет ускорить разработку.
• Язык может лучше подходить для некоторой конкретной области по сравнению с языком общего назначения.
• Этот язык используется внутренними пользователями, которым требуется «более простая» среда программирования. Короткие программы написаны людьми, которые не являются разработчиками программного обеспечения, используя относительно простой синтаксис / API.

Примером здесь может служить Lua, используемый в Adobe Lightroom.

Итак, то, что мы делаем с Lua, - это, по сути, вся логика приложения от запуска пользовательского интерфейса до управления тем, что мы фактически делаем в базе данных. Практически каждый фрагмент кода в приложении, который можно охарактеризовать как принятие решений или реализацию функций, находится на Lua, пока вы не приступите к необработанной обработке, которая находится в C ++. ( Марк Гамбург Интервью: Adobe Photoshop Lightroom )

внешне

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

IBM очень успешно использовала языки сценариев в своей основной операционной системе VM-CMS . EXEC , EXEC / 2 и более поздние Rexx использовались во всей системе как внутри, так и снаружи. Различные приложения (например, XEDIT ) можно было создавать с помощью сценариев с использованием тех же языков, а внутренние приложения / утилиты (например, электронная почта) были написаны на языке сценариев и обеспечивали тесную интеграцию с ОС и другими инструментами. Клиенты создали и поделились многими скриптовыми инструментами и приложениями. DEC также предоставил DCL . Позже Microsoft поддерживала VBscript как язык сценариев в большинстве своих приложений, а в последнее время PowerShell(также пакетные файлы MS / DOS ). Оболочки Unix также имеют скрипты .

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

Примеры из реального мира будут включать:

• Большинство веб-браузеров, которые будут поддерживать встроенный JavaScript.

• Microsoft Office Suite - Excel Word и т. Д. Все они поддерживают встроенные сценарии VBA.

• Многие сетевые маршрутизаторы включают API-интерфейсы сценариев на разных языках TCL, Perl, Lua.

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

Иногда сценарии встроены в приложение, потому что это средство расширения основного приложения другими разработчиками. Чтобы охватить как можно более широкий круг языков программирования, хост может поддерживать несколько языков сценариев. Например, в JVM вы можете встроить целый ряд совместимых с JSR-223 языков , включая Python, Ruby, JavaScript и т. Д.

Другая причина, которая еще не упоминалась, заключается в том, что встроенный язык имеет одну или несколько выдающихся функций, которые основной язык не может легко скопировать. Примером этого может быть функциональность Parse или создание DSL (предметно-ориентированного языка / диалекта) без усилий, которое можно найти на языке, подобном Rebol.

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

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

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

Моя конкретная ситуация, когда я использую интерпретируемый язык сценариев в главном приложении:

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

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

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

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

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

Исходя из моего опыта, мы однажды разработали большое приложение, которое переписывает исходный код «древнего» языка для совместимости с юникодом. Это было сделано в C #. В итоге я написал только движок (который создает модель данных и предоставляет средства для выполнения шагов, необходимых для процесса перезаписи) на C # - «склеивающий код» для фактического выполнения вещей выполняется в IronPython.

Самый важный момент для интегрированного IronPython: предположим, вы загрузили большую модель данных (время загрузки около часа). Затем вы хотите - вручную - собирать информацию и искать вещи. Делать это с помощью скрипта Python из интерактивной консоли гораздо лучше, чем перелистывать модель данных с помощью отладчика (плюс, он воспроизводим).

Есть несколько причин.

• Кривая обучения. Практически каждый может учиться и писать в JavaScript.
• Безопасность. Трудно контролировать контекст безопасности кода скрипта в C # или Java. Javascript идеально подходит для этого. Автор сценария никогда не сможет получить доступ к диску или куда-либо еще, если не разрешит им. Основной движок JavaScript - это просто продвинутый калькулятор.
• Качество. Вы устанавливаете очень толстый лимит для скриптового кода. Уровни «кода спагетти» очень различны для Javascript или C # / Java. (Что мешает тебе открыть врата ада)
• Тип безопасности. C # / Java являются типобезопасной средой, в большинстве случаев вы не предпочитаете ее в среде сценариев. Выражение типа «12» + 3 дает «123» в javascript, но C # / Java даже не скомпилируется. Авторы сценариев в основном даже не знают, что такое «тип»
• Динамический. Любой объект может содержать любое свойство / метод и может изменить его тип во времени. Например, я мог бы предоставить прокси-объект C # для среды сценариев, которая представляет XML-узлы в качестве свойств.
• Производительность. Обычно написание скрипта намного проще, чем на C # / Java. Не требуется компиляция или «регистрация плагинов». Вы можете напрямую редактировать содержимое скрипта в приложении с немедленными результатами.
• Управление. Использование C # / Java требует, чтобы SDK был ссылкой на плагины, которые выставляют внутренние классы миру. Эта архитектура плагинов требует «обратной совместимости» для старых версий SDK. Эта архитектура заставляет вас создавать «виртуальные» доменные объекты, которые обеспечивают внутренний механизм приложения в контексте домена. Это более управляемо / гибко, чем показ API.

Когда? В период с 1948 по 2008 гг. Изначально скомпилированным языкам требовалось значительное время для компиляции и компоновки, поэтому было довольно распространенным создавать язык сценариев, позволяющий настраивать и конфигурировать пользователя. Если вы посмотрите на историю AutoLisp, то сначала ответом будет AutoCAD с языком сценариев внутри него, но это было постепенно прекращено в пользу предоставления интерфейса VBA с поддержкой сценариев, а затем .net.

С CLR включение программы C # или вызова программы Lua в существующую систему существенно не отличается по стоимости разработки, а среда выполнения .net поставляется с инструментами для генерации и компиляции на лету.

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

В средах, которые не предлагают генерацию и компиляцию кода «на лету», и считается желательным предлагать язык автоматизации общего назначения, а не предметно-ориентированный, вы все равно получите сценарии Lua или Python. Для инструментов, предлагающих интерфейс COM, этот язык сценариев будет C # или VB.net (MS Office, Sparx Enterprise Architect). Таким образом, наличие языка сценариев для программы, написанной на языке, который сам по себе достаточно прост, чтобы быть языком сценариев, является ненужным.