В чем разница между языком сценариев и обычным языком программирования?

В чем разница между языком программирования и языком сценариев? Например, рассмотрим C против Perl.

Единственная разница в том, что языки сценариев требуют только интерпретатора и не требуют компиляции и компоновки?

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

Например, Python интерпретируется и не требует компиляции и компоновки, как это делает Prolog. Я бы классифицировал оба из них как языки программирования.

Языки программирования предназначены для написания программного обеспечения. Они предназначены для управления крупными проектами. Они могут, вероятно, вызывать программы, читать файлы и т. Д., Но могут быть не так хороши, как язык сценариев.

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

Например, Bash плохо выполняет арифметику, что, вероятно, сделает написание крупномасштабного программного обеспечения в нем кошмаром.

Как своего рода эталонный тест: я бы никогда не написал музыкальный плеер на Perl, хотя, наверное, мог бы. Кроме того, я бы никогда не попытался использовать C ++ для переименования всех файлов в данной папке.

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

Классическая статья о языках сценариев - « Сценарии Джона К. Оустерхаута : программирование высокого уровня для 21-го века» , опубликованная в Computer 31 (3), 1998. Он провел различие между языками сценариев, с одной стороны, и языками системного программирования на другой.

Ousterhout охарактеризовал языки системного программирования как развивающиеся, чтобы заменить машинные языки для программирования. Они скрывают утомительные детали, такие как назначение регистров и последовательности вызова подпрограмм, предоставляют простые конструкции для написания циклов и других распространенных идиом потока управления и обеспечивают соблюдение правил набора текста. Они обычно реализуются (заранее) компилятором. Эти языки предназначены для написания программного обеспечения с нуля. Примерами являются C, C ++ и Java.

Напротив, языки сценариев, согласно Ousterhout, исходят из предпосылки, что уже существуют полезные программы, обычно написанные на языках системного программирования. Языки сценариев, такие как Perl, Python, Tcl, Visual Basic и оболочки Unix, предоставляют инструменты для объединения этих существующих программ в новые программы. Ousterhout охарактеризовал языки сценариев как «не типизированные» (включая то, что многие называют динамической типизацией), и как подчеркивающий быстрое развитие; они обычно осуществляются переводчиками.

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

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

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

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

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

Набор «языки сценариев» является подмножеством набора «языки программирования». Разница между C и Perl заключается в разнице между языком системного программирования и языком приложений, а также между интерпретируемым языком и скомпилированным языком.

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

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

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

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

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

Сравните «семейный автомобиль» и «спортивный автомобиль» или «журнал» и «газету». Я осмелюсь сказать, что было бы сложно придумать 100% надежное правило, позволяющее дифференцировать каждый семейный автомобиль от каждого спортивного автомобиля, который можно обобщить (это означает, что он не сводится к перечислению всех существующих автомобилей в каждой категории) и, по крайней мере, потенциально объективен ( то есть это было бы приемлемо для всех). Но эти термины все еще полезны на практике, потому что, хотя есть некоторые случаи, которые трудно решить, многие автомобили явно относятся к одной категории, а не к другой.

Различие, которое я еще не заметил, состоит в том, что при использовании по назначению время выполнения большинства сценариев будет зависеть от «макроскопических» операций, а выполнение микроскопических операций не окажет значительного влияния на общее время выполнения. Например, если программа анимации с трассировкой лучей может включать в себя язык сценариев с оператором render image, сценарий для создания анимации 240 кадров может занять четыре часа в операторе render image и всего четыре секунды на выполнение. все остальное. Даже если бы ускорить все, что находится за пределами механизма рендеринга, в миллион раз, это оказало бы меньшее влияние на общую производительность, чем ускорение механизма рендеринга на 0,1%.