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

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

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

Никакая причина сделать его еще не усложняла, чем это?

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

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

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

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

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

Теперь, маленькие и большие программы могут быть записаны на любом языке. Маленькая программа Java является сценарием. Например, Java "Привет Мировая" программа является сценарием, не системой. Большая программа или набор программ, записанных в PHP, является системой. Например, Facebook, записанный в PHP, является системой, не сценарием.

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

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

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

• Perl является языком программирования!
• Perl компилируется как Java и C++. Это только что скомпилировало намного быстрее!
• Perl имеет объекты и пространства имен и закрытия.
• Perl имеет IDE и отладчики и профилировщиков.
• Perl имеет обучение и поддержку и сообщество.
• Perl не является просто сетью. Perl не является просто системным администратором. Perl не является просто клейкой лентой Интернета.

, Почему мы должны даже различать язык как Java, который компилируется и Ruby, который не является? Каково значение в маркировке?

Для больше на этом, см. http://xoa.petdance.com/Stop_saying_script .

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

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

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

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

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

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

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

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

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

Я думаю, что у г-на Roberto Ierusalimschy есть очень хороший ответ или вопрос в 'Программировании в Lua':

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

Я рассматриваю язык сценариев как что-либо не требование откровенного тяжеловеса, чувствующего, что 'компиляция' ступает. Основная функция с точки зрения программистов: Вы редактируете код и выполняете его сразу же.

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

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

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

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

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

Это как порно, вы знаете, когда вы его видите. Единственное возможное определение языка сценариев:

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 - нет.

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

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

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

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

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

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

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

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

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

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

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

Одно разделение -

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

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

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

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

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

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

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

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

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

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

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

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

Так что я бы сказал, что разница (по крайней мере для меня) больше в том, как вы используете язык. Такие языки, как PHP, Perl, Ruby, можно использовать как «языки сценариев», но я обычно вижу их как «нормальные языки» (за исключением Perl, который, кажется, идет в обе стороны.

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

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

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

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

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

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

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

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

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

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

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

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

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

На этот вопрос существует множество возможных ответов.

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

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

Функциональное программирование или объектно-ориентированное программирование - это стили программирования ; вы можете писать в функциональном или объектно-ориентированном стиле практически на любом языке. Например, коммутатор виртуальной файловой системы Linux и модель драйвера Linux в значительной степени объектно-ориентированы, несмотря на то, что написаны на C, тогда как большая часть кода Java или C #, которую вы видите в Интернете, очень процедурна и совсем не объектно-ориентирована . OTOH, я видел очень функциональный код Java.

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

Итак, для себя я нашел следующее определение :

Язык - это язык сценариев (объектно-ориентированный язык / функциональный язык), если он оба

• облегчают создание сценариев (объектно-ориентированное программирование / функциональное программирование), то есть не только разрешает , но делает простым и естественным и содержит функции, которые помогают в этом, И
• поощряют и направляет вас к написанию сценариев (объектно-ориентированное программирование / функциональное программирование).

Итак, после пяти абзацев я пришел к следующему: «язык сценариев - это язык сценариев». Какое отличное определение. НЕТ.

Очевидно, теперь нам нужно взглянуть на определение «скриптинга».

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

Ну, во-первых, скрипты - это программирование. Это просто особый вид программирования.IOW: каждый сценарий - это программа, но не каждая программа - это сценарий; набор всех скриптов - это собственное подмножество набора всех программ.

По моему личному мнению, то, что создает сценарии сценариев и отличает их от других видов программирования, заключается в том, что…

Скрипты в значительной степени управляют объектами, которые

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

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

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

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

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

Обратите внимание, что аспект сценария полностью ортогонален всем другим аспектам языков программирования: язык сценариев может быть строго или слабо типизирован, строго или слабо типизирован, статически или динамически типизирован, номинально, структурно или типизирован с уткой, черт возьми, это может даже быть нетипизированным. Он может быть императивным или функциональным, объектно-ориентированным, процедурным или функциональным, строгим или ленивым. Его реализации можно интерпретировать, компилировать или смешивать.

Например, Mondrian - это ленивый функциональный язык сценариев со строго статической типизацией и скомпилированной реализацией.

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

• настоящий язык программирования: мой язык программирования
• язык сценариев: ваш язык программирования

Это похоже на способ, которым этот термин используется чаще всего.

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

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

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

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

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

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

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

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

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

Я просто перенесу свой ответ из повторяющегося вопроса

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

Например, когда-то давно веб-страницы в формате HTML были утомительны. Они всегда были статичными. Затем однажды Netscape подумала: «А что, если мы позволим браузеру читать и выполнять небольшие команды на странице?» Так и был сформирован Javascript.

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

Теперь, связано ли alert () каким-либо образом с C ++ или другим языком кода, который браузер фактически использует для отображения предупреждения? Конечно, нет.Тот, кто пишет «alert ()» на странице .html, не понимает, как браузер на самом деле отображает предупреждение. Он просто пишет команду, которую интерпретирует браузер.

Давайте посмотрим на простой код javascript

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

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

Мы называем эту последнюю серию команд «скриптом» (поэтому она заключена в теги