Коли мова вважається мовою сценаріїв? [зачинено]

Що робить мову мовою сценарію? Я чув, як деякі люди кажуть "коли його тлумачать замість складеного". Це зробило б PHP (наприклад) мовою сценаріїв. Це єдиний критерій? Або є інші критерії?

Дивитися також:

• Яка різниця між "сценарієм" і "додатком"?

Мова сценаріїв - це мова, яка "скриптує" інші речі, щоб виконувати завдання. Основна увага в першу чергу не полягає в тому, щоб створити власні додатки настільки, щоб отримати наявний додаток, щоб діяти так, як вам потрібно, наприклад, JavaScript для браузерів, VBA для MS Office.

Простий. Коли я ним користуюся, це сучасна динамічна мова, коли ви користуєтесь нею, це просто мова сценарію!

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

У деяких очах спосіб використання мови робить її скриптовою мовою (наприклад, розробники ігор, які розвиваються в основному на C ++, будуть сценаріювати об’єкти в Lua). Знову ж таки, рядки розмиті - мова може бути використана для програмування однією людиною, та ж мова може бути використана для мови скриптування іншою.

Це стаття з вікіпедії про мови сценаріїв:

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

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

"Сценарій - це те, що ви даєте акторам. Програма - це те, що ви даєте глядачам". - Ларрі Уолл

Я дійсно не думаю, що більше немає різниці. Часто так звані "скриптові" мови складаються - просто дуже швидко та під час виконання. І деякі мови "програмування" додатково компілюються під час виконання (подумайте про JIT), і перший етап "компіляції" - це перевірка синтаксису та роздільна здатність ресурсів.

Не зациклюйтесь на цьому, це дійсно не важливо.

Моє визначення буде мовою, яка зазвичай розповсюджується як джерело, а не як двійкова.

На це є багато можливих відповідей.

По-перше: це насправді не питання різниці між мовою скриптування та мовою програмування, оскільки мова сценаріїв - це мова програмування. Це більше питання про те, які ознаки роблять деякі мови програмування мовою сценаріїв, тоді як інша мова програмування не є мовою сценаріїв.

По-друге: насправді важко сказати, що таке мова XYZ, чи це XYZ "сценарій", "функціональне програмування", "об'єктно-орієнтоване програмування" чи що у вас є. Визначення поняття "функціональне програмування" є досить чітким, але ніхто не знає, що таке "функціональна мова програмування".

Функціональне програмування або об'єктно-орієнтоване програмування - це стилі програмування ; ви можете писати у функціональному стилі або об'єктно-орієнтованому стилі майже будь-якою мовою. Наприклад, Linux Virtual File System комутатор і Linux Driver Model сильно об'єктно-орієнтована , незважаючи написана на C, в той час як багато Java або C # код , який ви бачите в Інтернеті є дуже процедурної , а не об'єктно-орієнтована на всіх . ОТО, я бачив якийсь функціональний код Java.

Отже, якщо функціональне програмування та об'єктно-орієнтоване програмування - це просто стилі, які можна виконати будь-якою мовою, то як ви визначаєте "об'єктно-орієнтовану мову програмування"? Можна сказати, що об'єктно-орієнтована мова програмування - це мова, яка дозволяє об'єктно-орієнтоване програмування. Але це не так багато визначення: всі мови дозволяють об'єктно-орієнтоване програмування, тому всі мови об'єктно-орієнтовані? Отже, ви говорите, добре мова є об'єктно-орієнтованою, якщо вона змушує вас програмувати в об'єктно-орієнтованому стилі. Але це теж не мало визначення: усі мови дозволяють функціональне програмування, тому жодна мова не є об'єктно-орієнтованою?

Отже, для мене я знайшов таке визначення:

Мова - це сценарна мова (об'єктно-орієнтована мова / функціональна мова), якщо вона обома

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

Отже, після п’яти абзаців я дійшов до: "мова сценаріїв - це мова сценарію". Яке чудове визначення. НЕ.

Очевидно, що зараз нам потрібно розглянути визначення поняття «сценарій».

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

Ну, по-перше, сценарій - це програмування. Це просто особливий вид програмування. IOW: кожен сценарій - це програма, але не кожна програма - це сценарій; набір усіх сценаріїв є належним підмножиною набору всіх програм.

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

Сценарії багато в чому маніпулюють об'єктами, які

• не були створені за сценарієм,
• мають життя незалежно від сценарію та
• жити за межами домену сценарію.

Крім того, використовувані типи даних та алгоритми, як правило, не визначаються сценарієм, а зовнішнім середовищем.

Подумайте про сценарій оболонки: сценарії оболонок зазвичай маніпулюють файлами, каталогами та процесами. Більшість файлів, каталогів і процесів у вашій системі, ймовірно, не створені поточним сценарієм. І вони не зникають, коли сценарій закінчується: їхнє життя повністю не залежить від сценарію. І вони насправді не є частиною сценарію, вони також є частиною системи. Ви не запускали свій сценарій написанням Fileта Directoryкласами, ці типи даних не викликають ваших проблем: ви просто припускаєте, що вони є, і ви навіть не знаєте (і не потрібно знати), як вони працюють. І ви також не реалізуєте власні алгоритми, наприклад, для обходу каталогів, який ви просто використовуєте, findзамість того, щоб реалізувати власний пошук в першу чергу.

Якщо коротко: скрипт приєднується до більшої системи, яка існує незалежно від сценарію, маніпулює деякою невеликою частиною системи, а потім виходить.

Ця більша система може бути операційною системою у випадку сценарію оболонки, DOM браузера у випадку сценарію браузера, гри (наприклад, World of Warcraft з Lua або Second Life з мовою скриптів Linden), програми (наприклад, AutoLisp мова для макросів AutoCAD або Excel / Word / Office), веб-сервер, пакет роботів або щось інше цілком.

Зауважте, що сценарій сценарію є повністю ортогональним для всіх інших аспектів мов програмування: мова сценаріїв може бути сильно або слабко набрана, строго або вільно набрана, статично або динамічно набрана, номінально, структурно або качка набрана, чорт може бути навіть нетипізованим . Він може бути імперативним або функціональним, об’єктно-орієнтованим, процедурним або функціональним, суворим або ледачим. Її реалізації можуть бути інтерпретовані, складені або змішані.

Наприклад, Mondrian - це строго сильно статично типізована лінива функціональна сценарна мова зі складеною реалізацією.

Тим НЕ менше, все це спірне питання, тому що шлях цей термін скриптова мова є дійсно використовується в реальному світі, не має нічого спільного з якою - небудь з перерахованого вище. Він найчастіше використовується просто як образа, а визначення досить просте, навіть спрощене:

• реальна мова програмування: моя мова програмування
• мова сценаріїв: ваша мова програмування

Це, мабуть, найчастіше використовується термін.

Це як порно, ви знаєте це, коли його бачите. Єдине можливе визначення мови сценаріїв:

A language which is described as a scripting language.

Трохи кругові, чи не так? (До речі, я не жартую).

В основному, немає нічого, що робить мову мовою сценарію, крім того, що її називають такою, особливо її творцями. Основний набір сучасних мов сценаріїв - PHP, Perl, JavaScript, Python, Ruby та Lua. Tcl - перша основна сучасна сценарна мова (хоча це була не перша мова сценаріїв, я забуваю, що це таке, але я з подивом дізнався, що вона передувала Tcl).

Я описую особливості основних мов сценаріїв у своїй роботі :

 A Practical Solution for Scripting Language Compilers
 Paul Biggar, Edsko de Vries and David Gregg
 SAC '09: ACM Symposium on Applied Computing (2009), (March 2009)

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

Залишається лише питання - як ви можете сказати, чи є нова мова сценарієм. Що ж, якщо це називається сценаристичною мовою, це одна. Отже, " Фактор" - це сценарна мова (або, принаймні, коли це було написано), але, скажімо, Java - це не так.

"Мова сценарію" - одне з тих нечітких понять, яке може означати багато речей. Зазвичай це стосується того, що існує покроковий процес, який веде вас від вихідного коду до виконання.

Наприклад, у Perl ви робите: perl my_source.pl

З огляду на вищезазначені критерії, PHP - це сценарій мови (навіть якщо ви можете мати процес "компіляції", наприклад, використовуючи Zend Encoder для "захисту" вихідного коду).

PS. Часто (але не завжди) інтерпретуються мови сценаріїв. Також часто (але знову ж таки не завжди) мови сценаріїв динамічно набираються.

Усі мови сценаріїв - це мови програмування. Так строго кажучи, різниці немає.

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

Я думаю, що пан Роберто Ієрусалімський має дуже гарну відповідь або питання на тему "Програмування в Луї":

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

Один поділ є

• сценарій = динамічно інтерпретується
• нормальний = складений

Динамічно інтерпретована мова інтерпретується під час виконання, тоді як скомпільована мова складається перед виконанням.

Додам, що, як зазначив Йорг, розрізнене / складене розрізнення є не особливістю мови, а механізмом виконання.

Можливо, вас також зацікавить це пояснення системи Type , яка пов'язана і більше зосереджена на мовному аспекті, а не на механізмі виконання. Більшість мов сценаріїв динамічно набираються, тоді як "звичайні" мови в основному мають статичний тип.

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

Мова сценарію зазвичай :

1. Динамічно набраний
2. Інтерпретована, з дуже маленьким акцентом на продуктивність, але хороша портативність
3. Потрібен набагато менший код котла , що призводить до дуже швидкого прототипування
4. Використовується для невеликих завдань, підходить для написання одного файлу для запуску якогось корисного «сценарію».

Хоча мова без сценарію зазвичай : 1. Статистично набрана 2. Скомпільована, з акцентом на продуктивність 3. Потрібно більше кодового коду, що призводить до уповільнення прототипування, але більшої читабельності та довгострокової ремонтопридатності 4. Використовується для великих проектів, адаптується до багатьох шаблони дизайну

Але це, на мій погляд, більше історична різниця. Javascript та Perl були написані на увазі невеликими, простими сценаріями, тоді як C ++ був написаний із складними програмами; але обидва можна використовувати будь-яким способом. І багато мов програмування, як сучасних, так і старих, все одно розмивають лінію (і в першу чергу це було нечітко!).

Сумно в тому, що я знаю декількох розробників, які ненавидять те, що вони сприймають як "мови сценарію", вважаючи їх більш простими і не такими потужними. Моя думка, що стара кліше - використовуйте правильний інструмент для роботи.

Мови сценаріїв спочатку розглядалися як механізми управління програмами, написаними жорсткою мовою програмування. Скомпільовані програми не могли бути змінені під час виконання, тому сценарії надавали людям гнучкість.

Найбільше, що сценарій оболонки - це автоматизація процесів у ядрі ОС (традиційно AppleScript на Mac); роль, яка все більше і більше переходила до рук Перла, а потім з нього переходила в Пітон останнім часом. Я бачив схему (особливо в її здійсненні Guile), яка використовується для оголошення сцен сцени; і останнім часом Lua користується великою популярністю як мова програмування для ігор-скриптів - до того, що єдиною важко кодованою річчю у багатьох нових іграх є графіка / фізика, а вся логіка гри закодована в Lua. Таким же чином, вважалося, що JavaScript сценарій поведінки веб-браузера.

Мови звільнилися; зараз ніхто не думає про ОС як про додаток (або про це взагалі багато думає), і багато колишніх мов скриптів стали використовуватись для написання власних повноцінних додатків. Сама назва стала безглуздою і поширилася на багато інтерпретованих мов, які використовуються сьогодні, незалежно від того, вони призначені для інтерпретації з іншої системи чи ні.

Однак "мови сценаріїв", безумовно, не є синонімом "інтерпретованих мов" - наприклад, BASIC інтерпретували більшу частину свого життя (тобто до того, як вона втратила свою акронімічність і стала Visual Basic), але ніхто не думає про це як сценаріїв.

ОНОВЛЕННЯ: Матеріали для читання, як зазвичай, доступні у Вікіпедії .

По-перше, мова програмування - це не "сценарій мови" чи щось інше. Це може бути "сценарна мова" і щось інше.

Другий момент, реалізатор мови скаже вам, чи це мова сценаріїв.

Ваше запитання повинно читати "У яких реалізаціях мовою програмування вважатимуться мовою сценаріїв?", А не "Яка різниця між мовою сценаріїв та мовою програмування?". Між ними немає.

Тим не менш, я вважаю мову мовою сценаріїв, якщо вона використовується для надання якогось середнього посуду. Наприклад, я вважаю, що більшість реалізацій JavaScript є сценарієм мови. Якщо JavaScript запускався в ОС, а не в браузері, це не буде мовою сценаріїв. Якщо PHP працює всередині Apache, це мова сценаріїв. Якщо це запускається з командного рядка, це не так.

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

Таким чином, я б розглядав JavaScript та PHP як мови сценаріїв, тоді як ActionScript 3 / Flex насправді не є.

Ми з моїм другом щойно мали такий аргумент: в чому різниця між мовою програмування та мовою сценаріїв.

Популярний аргумент полягає в тому, що мови програмування складаються і інтерпретуються мови сценаріїв. Однак я вважаю, що цей аргумент є абсолютно помилковим ... чому?

1. Chakra & V8 (механізми JavaScript і JavaScript Google) збирають код перед виконанням
2. QBasic інтерпретується - чи це робить Qbasic "скриптовою" мовою?

Виходячи з цього, це мій аргумент для різниці між мовою програмування та мовою сценаріїв:

Мова програмування працює на рівні машини і має доступ до самого апарату (пам'ять, графіка, звук тощо).

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

У своїй думці я б сказав, що мови, що динамічно інтерпретуються, такі як PHP, Ruby тощо), як і раніше, є "нормальними" мовами. Я б сказав, що прикладами "скриптових" мов є такі речі, як bash (або ksh, tcsh чи що завгодно) або sqlplus. Ці мови часто використовуються для з'єднання існуючих програм у системі в ряд узгоджених та пов'язаних команд, таких як:

1. скопіюйте A.txt в / tmp / робота /
2. запустити процес нічного очищення на сервері баз даних
3. записуйте результати та надсилайте їх до системи

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

Я просто продовжу і перенесу свою відповідь із дублюючого питання

Назва "Мова сценаріїв" стосується дуже специфічної ролі: мови, якою ви пишете команди для надсилання до існуючої програмної програми. (як-от традиційний телевізор чи фільм "сценарій")

Наприклад, колись HTML-сторінки були нудними. Вони завжди були статичними. Тоді одного разу Netscape подумав: "Ей, що робити, якщо ми дозволимо браузеру читати та діяти на маленькі команди на сторінці?" І так було сформовано Javascript.

Проста команда javascript - це alert()команда, яка вказує / командує браузер (програмний додаток), який читає веб-сторінку, для відображення попередження.

Тепер так alert() стосується якимось чином C ++ або будь-яка мова коду, яку браузер насправді використовує для відображення сповіщення? Звичайно, ні. Хтось, хто пише "alert ()" на сторінці .html, не розуміє, як браузер насправді відображає попередження. Він просто пише команду, яку браузер буде інтерпретувати.

Подивимося простий код JavaScript

<script>
var x = 4
alert(x)
</script>

Це інструкції, які надсилаються до браузера, щоб браузер інтерпретував сам себе. Мова програмування, через який переглядає браузер, фактично встановлює змінну до 4, і ставить це в попередження ... вона абсолютно не пов'язана з JavaScript.

Ми називаємо цю останню серію команд «скриптом» (саме тому вона укладена в <script>теги). Просто за визначенням «сценарій», у традиційному розумінні: Серія інструкцій та команд, що надсилаються акторам . Всім відомо, що сценарій (сценарій фільму), наприклад, є сценарієм.

Екран (сценарій) - це не актори, ані камера, ані спеціальні ефекти. Сценарій просто говорить їм, що робити.

Тепер, що саме є сценарієм мови ?

Є багато мов програмування, подібних до різних інструментів в панелі інструментів; деякі мови були розроблені спеціально для використання в якості сценаріїв.

Javasript - очевидний приклад; Є дуже мало додатків Javascript, які не підпадають під сферу сценаріїв.

ActionScript (мова для анімації Flash) та її похідні - це сценарій мови, оскільки вони просто видають команди Flash-програвача / інтерпретатора. Звичайно, є такі абстракції, як об'єктно-орієнтоване програмування, але все це просто засіб до кінця: надсилайте команди на флеш-програвач.

Python і Ruby зазвичай також використовуються як мови сценаріїв. Наприклад, я колись працював у компанії, яка використовувала Ruby для команд скриптів, щоб надсилати до браузера, який був уздовж рядка "перейдіть на цей сайт, натисніть на це посилання ...", щоб зробити кілька основних автоматизованих тестувань. Я не був "розробником програмного забезпечення" будь-яким способом на цій роботі. Я просто писав сценарії, які надсилали команди на комп’ютер, щоб відправляти команди в браузер.

Через їх природу мови сценаріїв рідко «складаються» - тобто переводяться в машинний код і читаються безпосередньо комп’ютером.

Навіть програми GUI, створені з Python та Ruby, є скриптами, що надсилаються в API, написаний на C ++ або C. Це повідомляє додатку C, що робити.

Звичайно, існує лінія розпливчастості. Чому ви не можете сказати, що Machine Language / C - це сценарій мови, оскільки це сценарії, які комп'ютер використовує для взаємодії з базовою материнською платою / графічними картами / чіпами?

Є кілька ліній, які ми можемо зробити для уточнення:

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

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

Чи можу я припустити, що мови мов сценаріїв - це термін, від якого віддаляються багато людей. Я б сказав, що в основному це зводиться до складених мов та динамічних мов.

Я маю на увазі, що ви насправді не можете сказати щось на зразок Python, або Ruby - це "скрипти" мови в цей день і вік (у вас навіть є такі речі, як IronPython та JIT - ваша улюблена мова , різниця ще більше розмилася).

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

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

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

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

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

Я вважаю за краще, щоб люди не використовували термін "мова сценарію", оскільки я думаю, що це зменшує зусилля. Візьміть таку мову, як Perl, яку часто називають "мовою сценарію".

• Perl - мова програмування!
• Perl компілюється як Java та C ++. Просто складено набагато швидше!
• У Perl є об'єкти та простори імен та закриття.
• У Perl є IDE та налагоджувачі та профілі.
• Perl має навчання та підтримку та громадськість.
• Perl - це не просто Інтернет. Perl - це не просто сисадмін. Perl - це не просто клейка стрічка Інтернету.

Чому нам навіть потрібно розрізняти таку мову, як Java, яка компілюється, і Ruby, яка не є? Яке значення в маркуванні?

Більше про це див . У розділі http://xoa.petdance.com/Stop_saying_script .

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

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

Для мов сценаріїв відносно звичайно можна підтримувати інтерактивний сеанс, коли користувачі можуть просто ввести свою програму і негайно виконати її. Це тому, що це тривіальне розширення суттєвої вимоги з першого абзацу; Основна додаткова вимога - це додавання механізму, який дозволяє з'ясувати, коли введений оператор завершений, щоб його можна було надіслати механізму виконання.

Для дещо іншого прийміть питання. Мова сценаріїв - це мова програмування, але мова програмування не обов'язково є мовою сценаріїв. Мова керування сценаріями використовується для управління або скриптування системи. Ця система могла б бути операційною системою, де мова скриптів буде битись. Система може бути веб-сервером з мовою сценаріїв PHP. Мови сценаріїв призначені для заповнення конкретної ніші; вони є доменними мовами. Інтерактивні системи інтерпретують мови сценаріїв, що породжує уявлення про інтерпретацію мов сценаріїв; однак це є наслідком системи, а не самої мови сценаріїв.

Мова сценаріїв - це мова, яка налаштовує або розширює існуючу програму.
Мова сценаріїв - мова програмування.

Визначення "мови сценаріїв" досить нечітке. Я б базував його на таких міркуваннях:

1. Мови сценаріїв зазвичай не мають видимих ​​користувачем кроків компіляції. Зазвичай користувач може просто запускати програми в одній простій команді.

2. Програми на мовах сценаріїв зазвичай передаються у вихідному вигляді.

3. Мови сценаріїв, як правило, мають час виконання, який присутній у великій кількості систем, а час виконання може бути легко встановлений у більшості систем.

4. Мови сценаріїв, як правило, є платформними та не специфічними для машини.

5. Мови скриптування спрощують виклик інших програм та інтерфейс з операційною системою.

6. Мови сценаріїв зазвичай легко вбудовуються у більші системи, написані більш звичайними мовами програмування.

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

Деякі з перерахованих вище характеристик стосуються реалізацій, і в цьому випадку я маю на увазі більш поширені реалізації. Були C-інтерпретатори, у яких (AFAIK) немає очевидного кроку компіляції, але це не стосується більшості реалізацій C. Ви, безумовно, можете скласти програму Perl з початковим кодом, але це не так, як зазвичай використовується. Деякі інші характеристики мають соціальний характер. Деякі з перерахованих вище критеріїв дещо перетинаються. Як я вже сказав, визначення нечітке.

Я б сказав, що мова сценаріїв - це те, що сильно маніпулює сутністю, яке воно не визначає. Наприклад, JavaScript маніпулює об'єктами DOM, наданими браузером, PHP управляє величезною бібліотекою функцій на основі С тощо. Звичайно, не точне визначення, більше спосіб подумати, чи це так.

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

Немає причин зробити це складніше, ніж це?

Звичайно, у більшості (99%) випадків зрозуміло, чи є мова сценарієм. Але врахуйте, що, наприклад, VM може імітувати набір інструкцій x86. Хіба це не зробить байтовий код x86 мовою сценаріїв під час роботи на VM? Що робити, якщо хтось повинен написати компілятор, який перетворить код Perl у нативний виконуваний файл? У цьому випадку я б більше не знав, як називати саму мову. Має значення вихід, а не мова.

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

Сценарій є відносно невеликою програмою. Система є відносно великий програмою, або колекція відносно великих програм.

Деякі мови програмування розроблені з функціями, які дизайнер мови та спільнота програмування вважають корисними при написанні відносно невеликих програм. Ці мови програмування відомі як мови сценаріїв , наприклад PHP.

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

Тепер малі та великі програми можна писати будь-якою мовою. Невелика програма Java - це сценарій. Наприклад, програма Java "Hello World" - це сценарій, а не система. Велика програма, або колекція програм, написана на PHP - це система. Наприклад, Facebook, написаний на PHP, - це система, а не сценарій.

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

Отже, мова - це сценарій мови, якщо вона зазвичай використовується для написання сценаріїв . Мова написання може бути використана для запису систем, але такі програми, ймовірно, вважатимуться сумнівними.