Встраиваемый скриптовый язык что это

СКРИПТОВЫЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Липаткин В.В.

В статье рассматриваются языки сценариев (скриптовые языки), их особенности и преимущества перед компилируемыми языками в определённых проектах.

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Липаткин В.В.

Скриптовый язык «Link» для программирования сценариев исполняемых событийных систем
Инструментальные средства создания веб-приложений на примере образовательного портала
Возможности нового объектно-ориентированного языка программирования ObjectScript
ОБЗОР ЯЗЫКОВ ПРОГРАММИРОВАНИЯ
Методы предварительной оптимизации программ на языке JavaScript
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «СКРИПТОВЫЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ»

Липаткин В.В. студент 2 курса

факультет «Информационных систем и технологий» Поволжский государственный университет телекоммуникаций и информатики

Россия, г. Самара СКРИПТОВЫЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ

В статье рассматриваются языки сценариев (скриптовые языки), их особенности и преимущества перед компилируемыми языками в определённых проектах.

Ключевые слова: скрипт, сценарий, интерпретация, компиляция, классификация, преимущества.

Язык сценариев, или же скриптовый язык (англ. — scripting language) -это язык программирования, разработанный для записи последовательностей операций — сценариев.

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

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

1. прочитать инструкцию;

2. анализировать инструкцию и применить соответствующие действия;

3. выполнить действие;

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

Скриптовые языки программирования по назначению можно разделить на три типа:

В эту категорию входят языки пакетной обработки и языки командных оболочек. Используются для управления заданиями в операционных системах. К ним относятся: JCL, sh (bash, csh, ksh), command.com, VB Script, PowerShell.

Прикладные (встраиваемые) сценарные языки

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

Дизайн такого языка отражает специфику выбранной области применения.

К этому типу относятся: AutoLisp, ECMAScipt и его диалекты (Jscript, JavaScript, ActionScript), ERM, Game Maker Language, UnrealScript, LotusScript, VBA и другие.

Языки общего назначения

Эта категория языков наиболее известна, особенно в применении к веб-программированию. К ним относятся: Tcl, Lua, PHP, Perl, Python, Ruby, REBOL.

Использование скриптовых языков имеет ряд преимуществ:

ш Кроссплатформенность: программы будут работать на любой платформе, где есть соответствующий интерпретатор (например, JavaScript исполняется браузерами на любой ОС);

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

ш Как правило, более наглядные средства диагностики ошибок в исходном коде;

ш Скриптовый язык имеет свой проблемно-ориентированный набор команд, и одна строка скрипта может делать то же, что десяток строк на обычном языке.

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

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

1. Богатырев Р. Природа и эволюция сценарных языков (рус.) // Мир ПК. — 2001. — № 11.

2. Roberto Ierusalimschy. Programming in Lua / lua.org; 2004 г. — 366 стр.

3. Wikipedia.org — свободная интернет-энциклопедия.

Встраиваемые языки: почему Lua?

Этот материал продолжает серию публикаций, основанных на докладах, которые мы сделали на конференции Games Gathering 2017 в декабре прошлого года. В одном из докладов была затронута тема выбора встраиваемого скриптового языка.

Что такое и зачем нужны скриптовые языки

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

Почему вообще возникает потребность в скриптовых языках? Как говорится, «в игровой индустрии нет сложных проблем, незачем требовать сложных решений» . Помимо опытных (и дорогих!) программистов, решающих сложные задачи, нам нужны люди (много людей!), которые будут заниматься, скажем, квестами. И, если честно, нам бы хотелось, чтоб эти программисты были не такие дорогие, а в идеале и вовсе не программисты, а непосредственно геймдизайнеры и сценаристы.

Таким образом, есть потребность в средстве для описания несложной, но всё-таки логики, без привлечения тяжёлой артиллерии программистов. Сделаем вывод — что такое для нас скриптовый язык? Это средство, которое позволит сделать разработку игр быстрее и дешевле.
Сразу возникает вопрос, а почему бы нам просто не использовать что-то вроде XML? Дело в том, что для наших целей нам часто нужны управляющие конструкции — ветвление и циклы, в то время как XML это декларативное описание.

Ещё одно преимущество скриптовых языков в том, что скрипты в проекте могут быть как кодом, так и ресурсом. И, соответственно, обновлять скриптовую часть игры можно не только вместе с кодом, то есть в ходе обычных обновлений через механизмы магазинов приложений. Но и вместе с ресурсами — то есть вместе с графическими и прочими материалами, с использованием CDN.

Требования к идеальному скриптовому языку

Сформулируем требования к идеальному скриптовому языку.

• Динамический. В нашем понимании идеальный скриптовый язык должен быть динамическим.
• Популярность. Под популярностью языка мы понимаем наличие у него достаточно большого сообщества, готового отвечать на вопросы на специализированных ресурсах наподобие StackOverflow.
• Пологая кривая обучения. Мы хотим взять, условно говоря, практически любого человека, и быстро обучить его до уровня, который позволит этому человеку продуктивно работать над нашими задачами.
• Широкие возможности. Язык должен быть мощным и обладать достаточно широкими возможностями, должен поддерживать разные парадигмы программирования. Профессиональный программист, которому предложат писать на таком языке, сможет делать это с комфортом и с удовольствием.
• Высокая производительность. Производительность — это один из краеугольных камней игровой индустрии.
• Большое количество библиотек. Очень часто мы, в ходе решения встающих перед нами задач, не создаём принципиально новый код, а пользуемся тем, что уже кто-то написал. Чем больше стабильных, хорошо поддерживаемых библиотек мы можем задействовать, применяя некий язык — тем лучше.
• Лёгкость встраивания. Речь идёт о встраиваемых языках, поэтому при выборе скриптового языка возможность его встраивания играет важную роль.

Python

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

Python обладает широкими возможностями, отличается хорошей производительностью. Его проблемой является неконсистентная система библиотек. Ещё одна его проблема, которая играет для нас важную роль, заключается в том, что он, на самом деле, не является встраиваемым языком. Это язык, из которого удобно вызывать библиотеки, написанные на C или C++.

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

В итоге можно сказать, что Python, при всех его сильных сторонах, нам не подходит. Теперь рассмотрим JavaScript.

JavaScript

JavaScript — это, без преувеличений, великий язык, который буквально захватил мир.

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

Если нам, для построения игрового движка, нужен какой-нибудь интерпретатор языка — мы можем найти множество таких интерпретаторов. В реальности же придётся выбирать из двух подобных проектов — V8 и WebKit. И тот и другой имеют достаточно большие размеры. Как результат, если речь идёт о настольных играх, можно было бы рискнуть и включить в игру весь интерпретатор, но в случае мобильных игр нас такой вариант не устраивает.

В компании SocialQuantum есть собственный интерпретатор JavaScript, который проходит 98% тестов, мы планируем перевести этот проект в разряд опенсорсных.

В результате оказывается, что JavaScript выглядит сильным кандидатом на роль встраиваемого языка, но нам он тоже не подходит.

Haxe

Тут надо отметить, что когда заходит разговор о JavaScript, следующим обычно вспоминают Haxe. Но, на самом деле, о возможности использования этого языка в качестве встраиваемого говорить нет смысла, так как Haxe, по сути, является не столько языком, сколько транс-компилятором в другие языки. А это не то, что нам нужно.

Может быть, нас устроит ActionScript или какой-нибудь другой скриптовый язык?

ActionScript

Если формально проанализировать ActionScript на соответствие вышеозначенным требованиям, то может показаться, что идеальный скриптовый язык найден. На его стороне динамическая природа, популярность, лёгкость изучения, хорошие возможности, производительность, наличие библиотек, лёгкость встраивания. Этот язык любят и помнят в игровой индустрии, на нём написано огромное количество замечательных Flash-игр. Главная проблема ActionScript заключается в том, что язык этот почти мёртв. Поэтому нас он тоже не устраивает.

AngelScript, Squirrel и другие

Помимо ActionScript существует множество скриптовых языков, таких, как AngelScript, Squirrel и другие. Среди них можно найти такие, которые, формально, почти полностью удовлетворяют нашим требованиям, но обычно это — языки, которые привязаны к их разработчику, в них бывают какие-то застарелые проблемы, которые годами не исправляются. Они, скорее всего, не слишком популярны, недостаточно хорошо документированы, по ним мало учебных материалов, у них не очень большие сообщества. Одним из следствий такого положения дел является тот факт, что их сложно изучать — хотя бы потому, что не до конца ясно — что они собой представляют и как работают.

Как видно, идеального встраиваемого языка мы пока не нашли. Что если создать собственный язык?

Создание собственного языка

Вполне возможно, что язык, разработанный внутри компании, будет идеально соответствовать её нуждам и его будет легко изучать. Но, скорее всего, такой язык не станет популярным. У такого языка либо будет минимальное количество библиотек, либо их не будет вовсе. Кроме того, сложно поверить, что в современных условиях можно создать нечто такое, что будет работать лучше, что будет обладать большей производительностью и будет проще встраиваться чем что-то, что уже есть на рынке.

Есть компании, которые разрабатывают и используют собственные языки, среди них есть и успешные игроки игрового рынка, но, скорее всего, это — не очень хорошая идея.

Рассмотрев существующие языки программирования, претендующие на роль встраиваемых и обсудив идею разработки собственного языка, перейдём к Lua.

Lua — встраиваемый язык, который выбрали мы

Lua — динамический язык. Он довольно-таки популярен, вокруг него сложилось большое сообщество, особенно — в сфере разработки игр. Он отличается весьма пологой кривой обучения. Например, в нашей компании сценарии для автотестов пишут на Lua. Стандартный вводный курс для автотестеров занимает примерно два часа, после чего человек в состоянии использовать этот язык. При этом Lua — мультипарадигменный язык. Он поддерживает функциональный стиль программирования и ООП. В результате он подходит не только для решения каких-то простейших задач, но и для более серьёзных дел, которыми занимаются профессиональные программисты.

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

Например, вот как выглядит наша рабочая среда на основе IDE CLion от JetBrains. Здесь можно видеть созданный нами механизм автодополнения для Lua, который планируется сделать опенсорсным. Опенсорсным мы собираемся сделать и отладчик.

Рабочая среда

Мы выбрали Lua, но, когда речь заходит об использовании его в качестве встраиваемого скриптового языка, обычно приходится сталкиваться с примерно одними и теми же возражениями, которые мы сейчас рассмотрим.

Возражения по поводу использования Lua

Lua предназначен для C а не для С++

Никто не спорит с тем, что Lua — отличный встраиваемый язык. Главное, что считают его минусом, заключается в том, что он создан для использования с языком C, а не C++. Из-за этого, пытаясь применить в Lua что-то такое, что есть в C++ и нет в C, мы сталкиваемся с проблемами. Однако тут надо понимать, что проблемы эти решало множество довольно умных людей. Среди средств, решающих проблемы встраивания Lua в C++-проекты, можно отметить такие, как Luabind, Luabridge, toLua++, SQLuaHost. Это — далеко не полный список. Они обладают разными достоинствами и недостатками, но, тем не менее, скорее всего, всё, что вам может потребоваться, уже реализовано в одном из этих решений.

Рассмотрим, например SQLuaHost. Это — биндинг, который сделан внутри компании SocialQuantum, и который планируется сделать опенсорсным. Это решение представляет наше видение того, как должен биндиться Lua. Поэтому, вполне возможно, что если вы не нашли то, что вам нужно в существующих биндерах, вы найдёте это в SQLuaHost.

Lua — это медленно

Нам часто приходится сталкиваться с мнением, в соответствии с которым Lua — это очень медленный язык. Во-первых — это не так. Lua — это стековая машина, и там, на самом деле, просто нечему тормозить. К тому же надо понимать, что в скриптовый язык мы обычно отдаём игровую логику, бизнес-логику, а не какие-то действительно тяжёлые вещи. В результате, если Lua-скрипты заставляют игру тормозить, то проблема, возможно, кроется в неоптимальном биндинге или в нерациональном использовании каких-то функция языка. Мы, например, проводили синтетические тесты, на которых LuaJIT работает быстрее, чем Mono. При этом никто не мешает писать примерно такой вот неоптимальный код:

function myGame:onUpdate() local tex = Texture::new(name) self.background:setTexture(tex) end

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

Lua подходит только для маленьких проектов

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

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

Другие аргументы против Lua

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

Говорят, что его минус в том, что в нём нет тернарного оператора. На самом деле, таких вот аргументов против Lua довольно много, но мы не будем их обсуждать, так как полагаем, что они, по большей части, относятся к привычкам и личным предпочтениям разработчиков.

Итоги

Подведём итоги. Если ваша задача — с минимальными усилиями обзавестись встраиваемым языком — возьмите Lua. В то же время, если у вас есть время и ресурсы на разработку собственного языка или собственных биндингов — опять же — обратите внимание на Lua. Почему и в первом и во втором случаях мы рекомендуем Lua?

В первом случае, выбрав Lua, вы выберете язык, который очень просто встраивать и использовать. Существует ровно одна обучающая книга по этому языку, написанная его автором. Других книг нет просто потому, что в первой рассказано абсолютно всё, что нужно знать о Lua, и рассказывать о нём больше нечего. Lua — не идеальный и не самый распространённый в мире язык, но, по сумме критериев, это, определённо, один из лучших языков для встраивания. Он — лучший из того, что есть в нашем распоряжении прямо сейчас. К тому же, существует множество стандартных инструментов для Lua, которые сильно облегчают жизнь тем, кто им пользуется.

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

• Блог компании Social Quantum
• Программирование
• Lua

Встраиваемый скриптовый язык.

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

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

Сам сценарий (скрипт) должен выполняться как на клиенте, так и на сервере.

На текущий момент база клиента и сервера написана на Java (Android libGDX + Java WebSocket).
т.е. основной язык разработки java.

В идеале это скрипт должен выполняться в обвертке из JVM.

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

Буду признателен за любую информацию, идею.

#1
18:56, 7 мар 2020

Ну я для себя расширяемость решил подключением модулей в виде отдельных DLL
(У меня правда C#)
В общем пишем абстрактный класс который представляет из себя макет\болванчик игровой сущности.
Типо

Abstact NPC

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

Ну т.е. наверняка все что необходимо для модулей вполне можно описать на уровне хранения данных.

З.Ы. Сам модуль довольно просто загружается через рефликсию.
В модуле должен быть метод ака Load() который определяет все преднастройки модуля, подписывает на события и т.п.

#2
19:58, 7 мар 2020

Jeners
> Ну я для себя расширяемость решил подключением модулей в виде отдельных DLL

Оно то хорошо, но это DLL (т.е. Windows система), что крайне ограничивает использование. В Java так-же есть подгружаемые библиотеки (jar) такого плана, но есть несколько жирных — НО:
— их потом нельзя выгрузить;
— они могут определяться системами безопасности как вредоносное ПО;
— нельзя исправить «на лету» в консоли, придется пере собирать проект (компилировать этот модуль);

Где-то когда-то видел реализация скриптов на lay и perl, но оболочку для их выполнения на java я не встречал.

#3
20:01, 7 мар 2020

Скажем реализовать базовые функции NPC в таком модуле — это нормально, но прописывать сценарии поведения и диалоги — нет.

#4
20:19, 7 мар 2020

joub
> Скажем реализовать базовые функции NPC в таком модуле — это нормально, но
> прописывать сценарии поведения и диалоги — нет.
А что подразумевается под базовыми функциями?
Почему эти функции не прописать в саму игру? Или план в том, что каждый модуль будет содержать в себе сильно разнящиеся между собой механики игрового процесса?
Если так, то как ни странно лучше реально юзать DLL. Если это не так, то большая информации описания модуля, можно заснуть в базы данных. Да логику в том числе можно заснуть в бд.

• Имбирная Ведьмочка
• Участник

#5
4:46, 9 мар 2020

Воспользуюсь случаем и пропихну мою прелесть Lua.
Если есть возможность подключать нативные библиотеки — бери LuaJIT, это чуть ли не самая совершенная виртуальная машина вообще.
Если нет — в интернете должны быть реализации на чистой джаве. Например.

#6
15:11, 9 мар 2020

Delfigamer
И я, и я, и я того же мнения!
Я даже к Delphi LuaJIT прикручивал.
А для языков СИ диалекта — это родное.

Скриптовый язык

Скри́птовый язы́к (англ. scripting language , в русской литературе принято название язык сценариев) — язык программирования, разработанный для записи «сценариев», последовательностей операций, которые пользователь может выполнять на компьютере. Простые скриптовые языки раньше часто называли языками пакетной обработки (batch languages или job control languages). Сценарии обычно интерпретируются, а не компилируются (хотя всё чаще применяют компиляцию каждый раз перед запуском).

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

Плагины или скрипты?

Для написания пользовательских расширений могут использоваться как скрипты (в терминологии некоторых программ «макросы»), так и плагины (независимые модули, написанные на компилируемых языках; в некоторых программах они могут называться «утилитами», «экспортёрами», «драйверами»).

Скриптовый язык удобен в следующих случаях:

1. Если нужно обеспечить программируемость без риска дестабилизировать систему. Так как, в отличие от плагинов, скрипты интерпретируются, а не компилируются, неправильно написанный скрипт выведет диагностическое сообщение, а не приведёт к системному краху;
2. Если важен выразительный код. Во-первых, чем сложнее система, тем больше кода приходится писать «потому, что это нужно» — см., например, Hello World#Маргинальные примеры. Во-вторых, в скриптовом языке может быть совсем другая концепция программирования, чем в основной программе — например, игра может быть монолитным однопоточным приложением, в то время как управляющие персонажами скрипты выполняются параллельно. В-третьих, скриптовый язык имеет собственный проблемно-ориентированный набор команд, и одна строка скрипта может делать то же, что несколько десятков строк на традиционном языке. Как следствие, на скриптовом языке может писать программист очень низкой квалификации — например, геймдизайнер своими руками, не полагаясь на программистов, может корректировать правила игры;
3. Если требуется кроссплатформенность. Хорошим примером является JavaScript — его исполняют браузеры под самыми разными ОС.

У плагинов же есть три важных преимущества.

1. Готовые программы, оттранслированные в машинный код, выполняются значительно быстрее скриптов, которые интерпретируются из исходного кода динамически при каждом исполнении. Поэтому скриптовые языки не применяются для написания программ, требующих оптимальности и быстроты исполнения. Но из-за простоты они часто применяются для написания небольших, одноразовых («проблемных») программ.
2. Полный доступ к любому аппаратному обеспечению или ресурсу ОС (в скриптовом языке для этого должен существовать написанный на машинном коде API). Плагины, работающие с аппаратным обеспечением, традиционно называют драйверами.
3. Если предполагается интенсивный обмен данными между основной программой и пользовательским расширением, для плагина его обеспечить проще.

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

Типы скриптовых языков

Универсальные скриптовые языки

Встроенные в прикладные программы

Командные оболочки

Встраиваемые

• ActionScript — В средах Adobe Flash, Adobe AIR, Adobe Flex
• Браузерные языки: JavaScript, JScript
• Lingo — использующийся в редакторе Director, называют скриптовым
• Guile
• Io
• Lua
• Sleep
• Script.NET

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

Командные файлы интерпретаторов

Многие консольные утилиты поддерживают выполнение последовательности команд, заранее записанной в файл. Такие файлы тоже называют скриптами.

Примеры таких утилит:

• SQLPlus — выполняет команды SQL и PL/SQL в СУБД Oracle

• Скриптовые языки

Wikimedia Foundation . 2010 .