Чим відрізняється мова сценаріїв від звичайної мови програмування?

Яка різниця між мовою програмування та мовою сценаріїв? Наприклад, розглянемо C проти Perl.

Єдина різниця в тому, що мови сценаріїв вимагають лише перекладача і не потребують компіляції та зв’язування?

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

Наприклад, інтерпретація Python не потребує компіляції та посилання, як це робиться у Prolog. Я б класифікував обидва ці програми як мови програмування.

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

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

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

Як своєрідний орієнтир: я б ніколи не писав музичний плеєр в перл, хоч, мабуть, міг би. Так само я ніколи б не намагався використовувати C ++ для перейменування всіх файлів у заданій папці.

Ця лінія стає розмитою і розмитою. JavaScript, за визначенням "сценаріїв" мовою, все частіше використовується для розробки "веб-додатків", які більше в області програмного забезпечення. Так само Python спочатку підходив до багатьох рис мови сценаріїв, але бачить все більше програмного забезпечення, розробленого за допомогою Python як основної платформи.

Класична стаття про мови сценаріїв - сценарій Джона К. Оустерхаута : Програмування вищого рівня для 21 століття , опублікована в "Комп'ютері 31 (3)" 1998 року. інші.

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

На противагу цьому, мови написання сценаріїв, за словами Ousterhout, починаються з того, що там уже є корисні програми, зазвичай написані мовами системного програмування. Мови сценаріїв, такі як Perl, Python, Tcl, Visual Basic та оболонки Unix, надають інструменти для комбінування цих існуючих програм у нові програми. Ousterhout характеризував мови сценаріїв як "безтипові" (включаючи те, що багато хто називає динамічним набором тексту), і як наголос на швидкому розвитку; вони, як правило, реалізуються перекладачами.

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

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

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

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

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

Набір "мови скриптування" - це підмножина набору "мови програмування". Різниця між C та Perl - це різниця між мовою програмування системи та мовою програми та між інтерпретованою мовою та мовою компіляції.

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

Таким чином, мови додатків, як правило, набагато вищого рівня, ніж системні мови, тобто забезпечують велику кількість вбудованих засобів абстрагування та помічників і часто додають певного автоматичного управління пам'яттю.

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

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

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

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

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