Когда язык считается языком сценариев? [закрыто]

Что делает язык скриптовым языком? Я слышал, как некоторые люди говорят: «когда он интерпретируется, а не компилируется». Это сделало бы PHP (например) языком сценариев. Это единственный критерий? Или есть другие критерии?

Смотрите также:

• В чем разница между «скриптом» и «приложением»?

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

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

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

В некоторых глазах то, как вы используете язык, делает его языком сценариев (например, разработчики игр, которые разрабатывают в основном на C ++, будут создавать сценарии для объектов в Lua). Опять же, границы размыты - язык может использоваться для программирования одним человеком, а тот же язык может использоваться для языка сценариев другим.

Это из статьи в Википедии о языках сценариев:

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

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

«Сценарий - это то, что вы даете актерам. Программа - это то, что вы даете зрителям». - Ларри Уолл

Я действительно не думаю, что есть большая разница. Так называемые «скриптовые» языки часто компилируются - просто очень быстро и во время выполнения. И некоторые из «языков программирования» также компилируются во время выполнения (подумайте о JIT), и первый этап «компиляции» - это проверка синтаксиса и разрешение ресурсов.

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

Мое определение - это язык, который обычно распространяется как исходный код, а не как двоичный.

На это есть много возможных ответов.

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

Во-вторых: действительно сложно сказать, что такое язык XYZ, будь то «скриптинг», «функциональное программирование», «объектно-ориентированное программирование» или что-то еще. Определение того, что такое «функциональное программирование», довольно ясно, но никто не знает, что такое «функциональный язык программирования».

Функциональное программирование или объектно-ориентированное программирование - это стили программирования ; вы можете писать в функциональном или объектно-ориентированном стиле практически на любом языке. Например, Linux Virtual File System коммутатор и Linux Driver Model сильно объектно-ориентированный , несмотря написана на C, в то время как много Java или C # код , который вы видите в Интернете является очень процедурной , а не объектно-ориентированный на всех . OTOH, я видел очень функциональный код 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)

Большинство из них динамически типизируются и интерпретируются, и большинство из них не имеют определенной семантики вне своей эталонной реализации. Однако, даже если их основная реализация будет скомпилирована или JIT-обработана, это не изменит «природы» языка.

Им остается только вопрос: как узнать, является ли новый язык языком сценариев. Что ж, если это называется языком сценариев, то это так. Итак, Factor - это язык сценариев (или, по крайней мере, был тогда, когда он был написан), но, скажем, Java - нет.

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

Например, в Perl вы делаете: perl my_source.pl

Учитывая вышеуказанные критерии, PHP является языком сценариев (даже если у вас может быть процесс "компиляции", например, при использовании Zend Encoder для "защиты" исходного кода).

PS. Часто (но не всегда) языки сценариев интерпретируются. Также часто (но опять же, не всегда) языки сценариев динамически типизируются.

Все языки сценариев являются языками программирования. Строго говоря, разницы нет.

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

Я думаю, что у г-на Роберто Иерусалимши есть очень хороший ответ на вопрос «Программирование на Lua»:

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

Одно деление

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

Динамически интерпретируемый язык интерпретируется во время выполнения, тогда как скомпилированный язык компилируется перед выполнением.

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

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

В целом разделение языков со статической и динамической типизацией лучше определено и имеет большее значение для удобства использования языка.

Язык сценариев обычно :

1. Динамически набираемый
2. Интерпретация, с очень небольшим упором на производительность, но с хорошей переносимостью
3. Требуется гораздо меньше шаблонного кода , что приводит к очень быстрому прототипированию
4. Используется для небольших задач, подходит для написания одного файла для запуска какого-нибудь полезного «скрипта».

В то время как язык без сценариев обычно : 1. Статически типизирован 2. Скомпилирован с упором на производительность 3. Требуется больше шаблонного кода, что приводит к более медленному созданию прототипов, но большей читабельности и долговременной ремонтопригодности 4. Используется для больших проектов, адаптируется ко многим шаблоны проектирования

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

Печально то, что я знаю нескольких разработчиков, которые ненавидят то, что они считают «языками сценариев», считая их более простыми и не такими мощными. Мое мнение - это старое клише - используйте правильный инструмент для работы.

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

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

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

Однако «языки сценариев» определенно не являются синонимами «интерпретируемых языков» - например, BASIC интерпретировался большую часть своей жизни (то есть до того, как он потерял свою аббревиатуру и стал Visual Basic), но никто на самом деле не думает об этом как сценарии.

ОБНОВЛЕНИЕ: материалы для чтения, как обычно, доступны в Википедии .

Во-первых, язык программирования - это не «язык сценариев» или что-то еще. Это может быть «скриптовый язык» и что-то еще.

Во-вторых, разработчик языка скажет вам, является ли это языком сценариев.

Ваш вопрос должен быть следующим: «В каких реализациях язык программирования будет считаться языком сценариев?», А не «В чем разница между языком сценариев и языком программирования?». Между ними нет.

Тем не менее, я буду рассматривать язык как язык сценариев, если он используется для создания промежуточного программного обеспечения. Например, я бы считал большинство реализаций JavaScript языком сценариев. Если бы JavaScript выполнялся в ОС, а не в браузере, он не был бы языком сценариев. Если PHP работает внутри Apache, это язык сценариев. Если он запускается из командной строки, это не так.

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

Таким образом, я бы рассматривал JavaScript и PHP как языки сценариев, а ActionScript 3 / Flex - нет.

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

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

1. Chakra & V8 (движки Microsoft и Google JavaScript) компилируют код перед выполнением
2. QBasic интерпретируется - делает ли это Qbasic "скриптовым" языком?

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

Язык программирования работает на машинном уровне и имеет доступ к самой машине (память, графика, звук и т. Д.).

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

В своем мнении я бы сказал, что динамически интерпретируемые языки, такие как PHP, Ruby и т. Д., По-прежнему являются «нормальными» языками. Я бы сказал, что примерами «скриптовых» языков являются такие вещи, как bash (или ksh, или tcsh, или что-то еще) или sqlplus. Эти языки часто используются для объединения существующих программ в системе в ряд последовательных и связанных команд, таких как:

1. скопируйте A.txt в / tmp / work /
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. Конечно, существуют абстракции, такие как объектно-ориентированное программирование, но все это просто средство для достижения цели: отправка команд во flash-плеер.

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

По своей природе языки сценариев редко «компилируются», то есть переводятся в машинный код и читаются непосредственно компьютером.

Даже приложения с графическим интерфейсом пользователя, созданные на Python и Ruby, представляют собой сценарии, отправляемые API, написанным на C ++ или C. Он сообщает приложению C, что делать.

Конечно, есть некоторая неясность. Почему вы не можете сказать, что Machine Language / C являются языками сценариев, потому что это сценарии, которые компьютер использует для взаимодействия с базовой материнской платой / видеокартой / чипом?

Вот несколько линий, которые мы можем прояснить:

1. Когда вы можете написать язык сценариев и запускать его без "компиляции", это больше похоже на прямой сценарий. Например, вам не нужно ничего делать со сценарием, чтобы указывать актерам, что с ним делать. Он уже есть, используется как есть. По этой причине мы исключим скомпилированные языки из списка языков сценариев, даже если в некоторых случаях они могут использоваться для написания сценариев.

2. Язык сценариев подразумевает команды, отправленные сложному программному приложению; Это и есть причина, по которой мы пишем сценарии в первую очередь - поэтому вам не нужно знать сложности того, как работает программное обеспечение, чтобы отправлять ему команды. Итак, языки сценариев, как правило, являются языками, которые отправляют (относительно) простые команды сложным программным приложениям ... в этом случае машинный язык и код сборки не сокращают его.

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

Я имею в виду, что вы не можете на самом деле сказать что-то вроде Python или Ruby - это «скриптовые» языки в наши дни (у вас даже есть такие вещи, как IronPython и JIT-your-favour-language , разница еще больше размыта).

Если честно, лично я больше не считаю 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 .

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

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

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

Для немного другого взгляда на вопрос. Язык сценариев - это язык программирования, но язык программирования не обязательно является языком сценариев. Язык сценариев используется для управления системой или создания сценариев для нее. Этой системой может быть операционная система, в которой языком сценариев будет bash. Система может быть веб-сервером с PHP в качестве языка сценариев. Языки сценариев предназначены для заполнения определенной ниши; они являются предметно-ориентированными языками. Интерактивные системы интерпретируют языки сценариев, что дает начало представлению об интерпретации языков сценариев; однако это следствие системы, а не самого языка сценариев.

Язык сценариев - это язык, который настраивает или расширяет существующую программу.
Язык сценариев - это язык программирования.

Определение «скриптовый язык» довольно расплывчато. Я бы основал это на следующих соображениях:

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

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

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

4. Языки сценариев имеют тенденцию быть кроссплатформенными, а не машинно-зависимыми.

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

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

7. Языки сценариев обычно разрабатываются для простоты программирования и гораздо меньше внимания уделяется скорости выполнения. (Если вам нужно быстрое выполнение, обычный совет - закодировать трудоемкие части на чем-то вроде C и либо встроить язык в C, либо вызвать биты C из языка.)

Некоторые из перечисленных выше характеристик верны для реализаций, и в этом случае я имею в виду более общие реализации. Были интерпретаторы C, в которых (AFAIK) не было очевидного шага компиляции, но это неверно для большинства реализаций C. Конечно, вы могли бы скомпилировать программу на Perl в машинный код, но обычно это не так. Некоторые другие характеристики носят социальный характер. Некоторые из приведенных выше критериев частично совпадают. Как я уже сказал, определение нечеткое.

Я бы сказал, что язык сценариев - это тот язык, который сильно манипулирует объектами, которые он сам не определяет. Например, JavaScript управляет объектами DOM, предоставляемыми браузером, PHP управляет огромной библиотекой функций на основе C и так далее. Конечно, не точное определение, скорее способ подумать, если это так.

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

Нет причин усложнять это дело?

Конечно, в большинстве (99%) случаев ясно, является ли язык языком сценариев. Но учтите, что виртуальная машина может, например, эмулировать набор инструкций x86. Разве это не сделало бы байт-код x86 языком сценариев при запуске на виртуальной машине? Что, если кто-то напишет компилятор, который превратит код Perl в собственный исполняемый файл? В этом случае я бы больше не знал, как называть сам язык. Будет иметь значение вывод, а не язык.

Опять же, я ничего подобного не знаю, поэтому пока мне удобно называть интерпретируемые языки скриптовыми языками.

Сценарий является относительно небольшой программой. система является относительно большой программой, или коллекция относительно крупных программ.

Некоторые языки программирования разработаны с функциями, которые разработчики языков и сообщество программистов считают полезными при написании относительно небольших программ. Эти языки программирования известны как языки сценариев , например PHP.

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

Теперь маленькие и большие программы можно писать на любом языке. Небольшая программа на Java - это сценарий. Например, программа Java «Hello World» - это сценарий, а не система. Большая программа или набор программ, написанных на PHP, - это система. Например, Facebook, написанный на PHP, - это система, а не скрипт.

Рассмотрение возможности одного языка как «лакмусовой бумажки» для определения того, какой язык лучше всего подходит для написания сценариев или системного программирования, вызывает сомнения. Например, сценарии могут быть скомпилированы в байтовый код или машинный код, или они могут выполняться путем прямой интерпретации абстрактного синтаксического дерева (AST).

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