Коли корисне використання мови сценаріїв у більшій програмі?

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

Якщо у вас є поведінка, вам не потрібно перекомпілювати програму, щоб змінити її. Саме тому так багато ігор використовують Lua як мову сценаріїв / моделювання.

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

• Веб-браузер (JavaScript)
• iOS (Objective-C)
• Windows (C ++ з Qt)
• Mac OS X (C ++ з Qt)
• Гойдалка Java (Java)

За допомогою цієї домовленості зробити версії моєї програми для різних операційних середовищ, а особливо підтримувати їх у курсі, набагато простіше.

Дуже широко є дві ситуації, коли ви застосували цю схему:

1. Це використовується для внутрішнього використання деякої якості вбудованої мови.
2. Це використовується для забезпечення зовнішньої програмованості.

Внутрішньо

• Зазвичай вбудована мова інтерпретується, що дозволяє швидко і швидко протестувати зміни без повторної компіляції.
• Вбудована мова може бути більш виразною, ніж мова, якою написано основну програму, що знову дозволяє швидше розвиватися.
• Мова може бути краще підходить для якогось конкретного домену порівняно з мовою загального призначення.
• Мовою користуються внутрішні користувачі, яким потрібна "простіша" мова програмування / середовища. Короткі програми пишуть люди, які не є розробниками програмного забезпечення, що використовують відносно простий синтаксис / API.

Прикладом тут може бути Lua, що використовується в Adobe Lightroom.

Тож, що ми робимо з 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 у ваші програми, підключити її до сокета та надати доступ до всієї системи.

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

Моя конкретна ситуація, коли я використовую інтерпретовану мову сценаріїв у головній програмі:

Є зовнішній пристрій, який виконує кілька функцій. Вимірювання, контроль, зчитування. Він досить «тупий» сам по собі і вимагає точного контролю, поетапно, включаючи безліч станів очікування та прийняття тимчасових рішень на стороні механізму управління.

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

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

Отже, замість цього є стан "виконати функцію без очікування", "виконати функцію блокування", "виконати функцію розгалуження / умовного / стрибка" в машині з кінцевим станом, можливо, всього шість станів. І є сценарії управління, які планується виконати, потім виконуються інтерпретатором, який управляє зовнішнім пристроєм, і їх результати розміщують там, де вони потрібні.

Підводячи підсумок, додаток: у RTOS використання внутрішньої інтерпретованої мови сценаріїв може значно знизити складність виконання завдань, що рясні в режимах очікування (функції блокування).

З мого досвіду, ми колись розробили великий додаток, який переписує вихідний код "стародавнього" мови, щоб бути сумісним з unicode. Це було зроблено в 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). Отож мати мову сценаріїв для програми, написаної мовою, яка сама по собі є достатньо простою для того, щоб бути мовою сценарію, - це зайве.