Языки сценариев типизированные

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

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

Языки программирования систем

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

В конце 50-х начали появляться языки более высокого уровня: Лисп, Фортран и Алгол, в которых уже не было однозначного соответствия между операторами и машинными командами; компилятор транслирует каждый оператор исходной программы в последовательность двоичных команд. В дальнейшем линия Алгола продолжилась в целом ряде языков программирования систем: PL/1, Паскаль, Си, С++ и Java. Постепенно они почти полностью вытеснили языки ассемблера при разработке больших приложений.

Языки высокого уровня

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

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

В среднем, каждая строка кода в языках программирования систем транслируется примерно в пять машинных команд, сравнительно с одной командой на строку в ассемблерной программе. В неформальном анализе восьми файлов на Си, написанных разными людьми, я обнаружил, что это отношение простирается от трех до семи команд на строку кода [1]; в своем известном исследовании Кейперс Джоунс (Capers Jones) показал, что для заданной задачи по сравнению с языками программирования систем языки ассемблера требуют написания большего количества строк кода в отношении от трех до шести раз [2]. Программисты могут писать примерно одно и то же количество строк кода за год независимо от языка [3], поэтому языки программирования систем позволяют создавать приложения быстрее, чем языки ассемблера.

Типизация

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

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

Современные языки программирования систем, напротив, сильно типизированы, например:

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

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

Языки сценариев

Языки Perl [4], Python [5], Rexx [6], Tcl [7], Visual Basic и оболочки Unix (shell) представляют стиль программирования, отличный от присущего языкам программирования систем. Этот стиль предполагает, что набор полезных в контексте решаемой задачи компонентов уже существует и остается должным образом их скомбинировать. Например, Tcl и Visual Basic могут служить для размещения на экране набора управляющих элементов пользовательского интерфейса, а написанные на shell командные файлы позволяют собрать программы-фильтры в конвейеры. Хотя языки сценариев часто используются для расширения свойств компонентов, они мало пригодны для программирования сложных алгоритмов и структур данных, обычно как раз и обеспечиваемых компонентами. Вот почему языки сценариев часто называют склеивающими языками (glue languages) или языками интеграции систем (system integration languages).

Бестиповость

Существует тенденция делать языки сценариев бестиповыми для упрощения связывания компонентов. Все сущности выглядят и ведут себя одинаковым образом, а значит могут стать взаимозаменяемыми. Например, в Tcl или Visual Basic переменная может в один момент содержать строку, а в следующий — целое число. Код и данные часто взаимозаменяемы, так что программа может генерировать другую программу и затем исполнять ее. Универсальным способом представления для различных сущностей программы в языках сценариев служат цепочки символов.

Языки сценариев весьма облегчают задачу «сцепления» компонентов. В них нет никаких заведомых ограничений — все компоненты и величины представляются единообразно, могут использоваться в любой ситуации. Компоненты, спроектированные для одной цели, могут в дальнейшем применяться для совершенно других целей, о которых и не думали их создатели. Например, в shell все программы-фильтры читают поток символов с устройства ввода и пишут его в устройство вывода. Любые две программы могут быть связаны путем присоединения выхода одной из них ко входу другой. Следующая команда shell соединяет вместе три фильтра для подсчета числа строк в выборке, содержащей слово «scripting»:

select | grep scripting | wc

Программа select читает текст, выбранный для вывода на дисплей, и выдает его в качестве своего выхода; программа grep, получив его на входе, выдает на выход строки, содержащие слово «scripting»; наконец, программа wc подсчитывает количество строк на своем входе. Каждая из этих программ может быть использована во многих других ситуациях при выполнении разнообразных задач.

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

Чтобы оценить по достоинству бестиповые языки, рассмотрим следующую команду на Tcl:

button .b -text Hello! -font (times 16) - command (puts hello)

Эта команда создает новую управляющую кнопку, предназначенную для отображения цепочки символов шрифтом Times размером 16 кеглей, и печатает короткое сообщение, когда пользователь щелкнет по этой кнопке. Команда смешивает шесть разных типов сущностей в один оператор: имя команды (button), управление кнопкой (.b), имена свойств ( -text, -font, -command), простые строки (Hello! и hello), описание шрифта (Times 16), включающее имя гарнитуры (Times) и размер (16), и, наконец, еще одну Tcl-команду (puts hello). Все эти сущности представляются единообразно, посредством цепочек символов. В этом примере свойства могут задаваться в любом порядке, а неспецифицированным свойствам дается значение по умолчанию.

При реализации на Java тот же пример требует 7 строк кода в двух методах. При использовании C++ и библиотеки базовых классов MFC потребуется около 25 строк в трех процедурах [1]. Только установка шрифта требует нескольких строк:

Cfont *fontPtr = new Cfont();
fontPtr -> CreateFont(16, 0, 0, 0, 700, 0, 0, 0, 
  ANSI_CHARSET,
  OUT_DEFAULT_PRECIS,
  CLIP_DEFAULT_PRECIS,
  DEFAULT_QUALITY,
  DEFAULT_PITCH|FF_DONTCARE,
  "Times New Roman");
buttonPtr -> SetFont(fontPtr);

Большая часть этого кода — следствие сильной типизации. Для установки шрифта кнопки управления должен быть вызван метод SetFont, но этому методу в качестве аргумента следует передать указатель на объект Cfont, что, в свою очередь, требует, чтобы новый объект был объявлен и инициализирован. Для инициализации объекта Cfont надо вызвать его метод CreateFont, но он имеет жесткий интерфейс, требующий задания 14 аргументов. В Tcl же существенные характеристики шрифта можно использовать без каких-либо деклараций или преобразований. Кроме того, Tcl позволяет включить поведение управляющей кнопки прямо в команду, которая эту кнопку создает, в то время как на C++ и Java для этого приходится писать отдельно декларируемый метод. (На практике с таким примером, вероятно, проще всего было бы справиться с помощью графической среды разработки, которая скрывает от пользователя сложность базового языка. Пользователь просто вводит величины свойств в форму, и среда разработки генерирует код. Однако в более сложных ситуациях, таких как назначение величин свойств в зависимости от различных условий или при необходимости генерировать интерфейсы «на лету», программисту все равно приходится оперировать базовым языком).

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

Интерпретируемость

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

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

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

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

Рисунок 1.
Сравнение языков на основе уровня программирования и силы типизации

Языки сценариев особенно удобны для быстрой разработки приложений — таблица 1, быть может не слишком строго, но наглядно иллюстрирует этот факт. В таблице описаны несколько приложений, либо сначала реализованные на языке программирования систем, а затем переписанные на языке сценариев, либо наоборот. «Сценарная» версия во всех случаях требовала меньше кода и времени разработки; коэффициент, выражающий эту разницу, варьировался от 2 до 60. Сценарные языки были менее эффективны, когда использовались для первой реализации; впрочем, и без того очевидно, что новая реализация всегда выигрывает от осмысления первого опыта. Так или иначе, от 5 до 10 — более правдоподобное значение коэффициента, выражающего разницу между написанием сценария и программированием систем, чем приведенные в таблице экстремальные значения. Результаты зависят, естественно, и от разрабатываемого приложения. В последнем примере из таблицы часть приложения, связанная с графическим пользовательским интерфейсом, реализована с помощью технологии склейки — в отличие от собственно моделирующей части; это объясняет, почему в данном случае сценарный подход обеспечил меньше преимуществ, чем в других приложениях.

Информация в таблице была получена от нескольких разработчиков на Tcl в ответ на статью, помещенную в comp.lang.tcl newsgroup.

Разные средства для разных задач

Языки сценариев не могут заменить языки программирования систем (впрочем, верно и обратное). Каждый из двух типов языков имеет собственную нишу. Если при создании приложений необходимо склеивать компоненты и интегрировать системы, то языки сценариев позволят сделать это в 5-10 раз быстрее. В то же время особенности языков программирования систем облегчают реализацию сложных алгоритмов и структур данных. Кроме того, языки программирования систем позволяют писать программы в 10-20 раз более быстрые, чем языки сценариев, поскольку содержат намного меньше операций проверки во время исполнения.

Можно сделать вывод, что оба типа языков должны использоваться в сочетании друг с другом. Например, системные программисты пишут компоненты ActiveX на Си, а их менее искушенные коллеги могут затем использовать эти компоненты при создании приложений с помощью Visual Basic. В Unix несложно писать командные файлы на shell, инициирующие работу приложений на Си. Одна из причин популярности Tcl — его способность к расширению путем создания новых команд, реализованных на Си.

Рост значимости языков сценариев

Итак, языки сценариев существуют долгие годы, но с недавних пор они начали играть более важную роль. Это стало результатом действия нескольких факторов. Самый важный из них — переход от простой «смеси» совместно используемых, но отдельно функционирующих приложений к «склеивающим» приложениям. Три слагаемых этого изменения: графические пользовательские интерфейсы, Internet и компонентные интегрированные среды.

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

Мне не приходилось слышать о каких-либо средах быстрой разработки графических пользовательских интерфейсов на основе языка программирования систем. В случае с Windows, Macintosh Toolbox или Unix Motif подобные средства, опирающиеся на Си или C++, всегда оказывались тяжелыми для изучения, неудобными и негибкими. В некоторых из перечисленных систем неплохие графические средства для проектирования экрана скрывают базовый язык — но не в тех случаях, когда дизайнеру приходится программировать, чтобы сгенерировать поведение для элементов интерфейса. Все лучшие среды быстрой разработки графических пользовательских интерфейсов основаны на языках сценариев: Visual Basic, HyperCard и Tcl/Tk.

Экспансия Internet во многом способствовала популяризации языков сценариев. В конце концов, Сеть — не что иное, как склеивающий инструмент. Она не создает новых данных или вычислительных процедур, а просто делает огромное множество уже существующих ресурсов более доступными. Идеальным для большинства задач в Internet был бы язык, способный обеспечить совместную работу всех связанных компонентов — язык сценариев. Например, Perl стал популярным средством для написания сценариев графических пользовательских интерфейсов, а JavaScript оказался удобным инструментом для сценарной разработки Web-страниц.

Третий пример сценарно-ориентированных приложений — компонентные интегрированные среды, такие как ActiveX и JavaBeans. Без хорошего языка сценариев, прямо предназначенного для манипулирования компонентами, потенциал интегрированных сред в значительной мере не получит реального воплощения. Не удивительно, что интегрированные среды завоевали столь большую популярность на ПК — ведь именно на этой платформе Visual Basic обеспечивает удобное средство для сценарно- ориентированных технологий, а на других платформах, например, Unix/CORBA, такого рода средства в компонентную интегрированную среду в явном виде не включены.

Еще одна причина популярности языков сценариев коренится в значительном прогрессе сценарно-ориентированных технологий. Современные языки сценариев Tcl и Perl далеко ушли от своих предшественников. Например, JCL не обеспечивал даже базового взаимодействия, а ранний shell не поддерживал процедур. Впрочем и сегодня сценарные технологии не достигли полной зрелости. Например, Visual Basic не является полноценным языком сценариев — он изначально проектировался как простой язык программирования систем и только затем приобрел свойственные языку сценариев черты.

Важный стимул для совершенствования сценарных технологий — постоянно увеличивающаяся производительность компьютеров. Еще недавно казалось, что единственный способ получить высокопроизводительное приложение — создать его на языке программирования систем, а то и на языке ассемблера. Однако, по сравнению с машинами двадцатилетней давности производительность увеличилась в 100-500 раз и продолжает удваиваться каждые 18 месяцев. Сегодня многие приложения, реализованные на интерпретируемом языке, имеют отличную производительность. Например, сценарий на Tcl может манипулировать множеством в несколько тысяч объектов и при этом обеспечивать приемлемое время отклика. Чем производительнее компьютеры, тем привлекательнее сценарно-ориентированные технологии для создания больших и сложных приложений.

Программисты по случаю

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

Программисты «по случаю» не склонны тратить месяцы на изучение языка, а хотели бы освоить его за несколько часов. В случае языков сценариев это вполне реально. Их легче осваивать, поскольку у них простой синтаксис и обычно опущены сложные конструкции наподобие объектов и потоков. Сравните Visual Basic и Visual C++ — мало кому из непрофессионалов может прийти сама мысль об использовании Visual C++, но очень многие с успехом пишут на Visual Basic.

Уже сегодня количество приложений, написанных на языках сценариев, превосходит число тех, что написаны на языках программирования систем. Это верно и для Unix-систем, в которых функционирует намного больше сценариев на shell, чем программ на Си; и для Windows, где больше приложений на Visual Basic, чем на Си или C++. Конечно, большинство сложных и наиболее распространенных приложений по-прежнему создается на языках программирования систем, так что сопоставление общего количества строк кода или числа установленных копий пока еще говорит в их пользу. Однако, языки сценариев стали основной движущей силой в разработке приложений, и их доля на рынке будет возрастать.

Роль объектов

Языки сценариев не избалованы вниманием экспертов в области языков и программной инженерии, которые сфокусировались на объектно-ориентированных языках программирования систем C++ и Java. Широко распространилось мнение, что именно объектно-ориентированное программирование представляет собой следующий шаг в эволюции языков. Утверждается, например, что такие его особенности, как сильная типизация и наследование сокращают время разработки, усиливают степень повторного использования компонентов и решают многие другие проблемы, включая и те, которые стоят перед языками сценариев.

Но действительно ли выгоды от объектно-ориентированного программирования столь велики? К сожалению, я пока еще не видел надежных количественных данных, чтобы с уверенностью дать утвердительный ответ на этот вопрос. По моему мнению, использование объектов способно принести достаточно скромные дивиденды: возможное увеличение в производительности я оцениваю в диапазоне 20-30%, а вовсе не в два и тем более не в 10 раз. Хорошо известно противоречивое отношение программистского сообщества к C++, а некоторые влиятельные эксперты начинают все громче высказываться вообще против объектно-ориентированного программирования как такового [8]. В любом случае, объекты не увеличивают производительность столь существенно, как сценарная технология, а обеспечиваемые ими преимущества могут быть достигнуты и с помощью языков сценариев.

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

Другая проблема объектно-ориентированных языков — их акцент на наследовании. «Наследование реализации», при котором один класс заимствует код, написанный для другого, — весьма сомнительная идея, приводящая к проблемам при разработке и повторном использовании: реализации классов привязываются друг к другу, так что ни один класс не может быть понят без другого. Подкласс нельзя понять без знания того, как унаследованные методы реализованы в его суперклассе, а суперкласс, в свою очередь, нельзя понять, не зная, какие из его методов наследуются в подклассах. В сложной иерархии классов, ни один отдельный класс не может быть понят без понимания всех других классов в иерархии. Что еще хуже, класс нельзя безболезненно выделить из иерархии для повторного использования. Множественное наследование делает проблему еще более тяжелой. Наследование реализации вызывает взаимное «переплетение» классов и их уязвимость, сходные с теми, что наблюдались, когда сверх меры использовали оператор goto.

Языки сценариев фактически ввели в действие принцип повторного использования. Модель, которой они следуют при создании приложений, предполагает, что необходимые компоненты могут быть встроены в язык программирования систем и затем склеены вместе с помощью языка сценариев. Такое «разделение труда» обеспечивает естественную схему для повторного использования. Компоненты проектируются в расчете на повторное использование, что и реализуется с помощью сценариев, использующих хорошо определенные интерфейсы между компонентами. В Tcl компонентами являются настраиваемые пользователем команды, реализуемые на Си; они выглядят подобно встроенным командам, поэтому их легко использовать в сценариях Tcl. В Visual Basic в качестве компонентов служат элементы ActiveX.

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

К счастью, сильные стороны объектов в языках программирования систем могут быть достигнуты и в языках сценариев, практически каждый из которых в той или иной степени поддерживает объектно-ориентированное программирование. Например, Python является объектно-ориентированным языком сценариев; последняя версия Perl включает поддержку объектов; Object Rexx является объектно-ориентированной версией Rexx, а Incr Tcl — объектно-ориентированное расширение Tcl. При этом сохраняется присущая языкам сценариев бестиповость объектов.

Другие языки

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

Заключение

Итак, языки сценариев предлагают иные по сравнению с языками программирования систем приоритеты: они пренебрегают заботой об эффективности и силе типизации, но значительно повышают продуктивность труда программистов и поощряют повторное использование. Это приобретает все больший смысл по мере того, как компьютеры становятся быстрее и дешевле, а программистский труд — дороже. Языки программирования систем хорошо подходят для создания компонентов, реализующих сложные алгоритмы и структуры данных, в то время как языки сценариев ориентированы на склеивающие приложения, где сложность скрыта в компонентах. «Склеивающая» технология становится все более распространенной при создании приложений; вот почему языки сценариев станут ведущей парадигмой программирования в 21 веке.

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

Литература

Об авторе: Джон Остераут (John Ousterhaut) — основатель и руководитель компании Scriptics. До недавнего времени работал в Sun Microsystems, где возглавлял проект SunScript. Его интересы включают сценарные языки, программирование для Internet, пользовательские интерфейсы и операционные системы. Джон известен в России как создатель языка сценариев Tcl и инструментария Tcl toolkit. Остераут удостоен многих престижных наград, в том числе премии ACM Grace Murray Hopper Award и Президентской премии Национального научного фонда США.

John K. Ousterhout «Scripting: Higher-Level Programming for the 21st Century», — Computer, Vol.31, N.3, March 1998. Reprinted with permission, Copyright IEEE CS. All rights reserved.

Выбор типа языка

• Является ли связывание уже существующих компонентов приоритетной задачей при построении приложения?
• Будет ли приложение манипулировать несколькими объектами разной природы?
• Включает ли приложение развитый графический пользовательский интерфейс?
• Предполагается ли в рамках приложения много манипулировать цепочками символов?
• Будет ли функциональность приложения меняться с течением времени?
• Должно ли приложение быть расширяемым?

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

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

В течение последние 30 лет в большинстве основных вычислительных платформ применялись средства обоих типов. Например, одним из первых языков сценариев был Job Control Language (JCL), использовавшийся для управления последовательностью шагов задания в OS/360. Сами же по себе отдельные шаги задания писались на PL/1, Фортране или языке ассемблера. В 80-х гг. на Unix-машинах для системного программирования служил Си, а для задания сценариев обработки — оболочки sh и csh. С наступлением эры ПК лидерами в сфере программирования систем стали Си и C++, а ведущим языком сценариев — Visual Basic. Наконец, в формирующемся на наших глазах мире Internet приоритетным языком программирования систем считается Java, а разработка сценариев ведется на JavaScript, Perl и Tcl.

Ошибка базы данных: Table ‘a111530_forumnew.rlf1_users’ doesn’t exist

Языки сценариев: что это такое и для чего они нужны?

Оригинал: Scripting Languages: What and Why?

Автор: Juliet Kemp

Дата публикации: 14 декабря 2016 г.

Перевод: А.Панин

Дата перевода: 8 января 2017 г.

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

Для чего это нужно?

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

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

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

Как правило, языки сценариев проектируются с целью достижения максимальной скорости изучения и разработки. Однако, ввиду того, что данные языки являются интерпретируемыми (это утверждение справедливо в большинстве случаев, но имеются и исключения, такие, как язык Ruby, который может быть как интерпретируемым, так и компилируемым в зависимости от реализации), созданные с их использованием сценарии зачастую исполняются медленнее, чем бинарные программы, созданные с использованием компилируемых языков программирования. Постоянно растущая популярность этих языков напрямую связана с постоянным повышением производительности доступного аппаратного обеспечения. Чем быстрее работает компьютер, тем меньшее значение будет иметь разница в скорости между интерпретируемыми и компилируемыми программами; при этом решающее значение будет иметь скорость процесса разработки. Пропуск этапа компиляции значительно упрощает цикл разработки и отлично сочетается с такими современными практиками программирования, как экстремальное программирования. При этом по мере увеличения объема кода и сложности программного обеспечения может появиться смысл в возврате к использованию компилируемого языка программирования.

На сегодняшний день в мире языков сценариев доминируют высокоуровневые динамические языки программирования общего назначения, обычно рассматриваемые как «связующие» языки, объединяющие несколько программных компонентов. Другие языки сценариев, такие, как Sed, Awk или (являющийся более современным) JavaScript являются предметно-ориентированными. JavaScript является встраиваемым языком, который используется исключительно в рамках определенных приложений или наборов приложений. Emacs Lisp является еще одним специфичным для приложения языком сценариев, при этом во многих играх используются собственные реализации языков сценариев или особые диалекты существующих языков сценариев. Наконец, языки для управления задачами и языки командных интерпретаторов, таких, как Bash, являются еще одной формой языков сценариев и обычно используются в качестве «связующих» языков для интерпретаторов и утилит с интерфейсом командной строки.

История развития языков сценариев

Первые мэйнфреймы не поддерживали широкого спектра механизмов (или вообще не поддерживали механизмов) взаимодействия с пользователями; вместо них использовались очереди задач. Для упрощения процесса обработки задач были разработаны различные языки, включая язык Job Control Language, созданный специалистами компании IBM.

В 1960 году на смену языкам обработки задач пришли интерактивные командные оболочки и сценарии, позволяющие автоматизировать запуск программ. Они позволили задействовать дополнительные удобные функции благодаря работе множества программистов. Язык TRAC, созданный Калвином Муерсом, принес идеи подстановки команд в сценариях, а также использования вывода этих команд в рамках этих же сценариев — этот механизм напоминает оператор обратных кавычек в современных командных оболочках.

Стьюарт Мадник из MIT разработал язык сценариев CMS EXEC (в оригинале имевший имя COMMAND) для IBM VM/CMS OS в конце 60-х годов прошлого века. Он поддерживал управляющие выражения различных типов (включая условные инструкции и циклы), а также несколько встроенных функций. Очевидно, что именно с данного момента началось развитие современных языков сценариев.

Множество Мандельброта

Множество Мандельброта определено на плоскости комплексных чисел (представленной, как система координат (x,y)). Для каждого комплексного числа c должна существовать ограниченная последовательность:

zk+1 = zk2 + c

Если для числа c последовательность является ограниченной, это число находится в множестве Мандельброта. Если же последовательность является неограниченной, число c не находится в множестве Мандельброта.

При расчете мы будем осуществлять 50-кратную итерацию в рамках последовательности и в том случае, если значение zk + 1 будет покидать окружность радиусом 2 вокруг значения c, мы будем делать вывод о том, что число c не находится в рассматриваемом множестве.

Наша система координат будет иметь ось x с координатами от -2 до 1 и ось y с координатами от -1 до 1. Мы будем отображать ее с помощью ASCII-символов начиная с верхнего левого угла (с координатами x=-2, y=1), причем вывод результатов будет заключаться в последовательном выводе строк по оси y. Каждый ASCII-символ (пробел или *) будет соответствовать сдвигу на 0.05 по оси координат. Вы сможете самостоятельно заменить жестко заданные значения для того, чтобы оценить полученные в результате изменения или добавить поддержку цветов для того, чтобы визуально усложнить вывод.

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

Perl

Ларри Уолл выпустил версию 1.0 интерпретатора языка Perl в 1987 году. Его цель заключалась в создании языка сценариев общего назначения для Unix, максимально упрощающего процесс обработки отчетов. Повышение производительности доступного аппаратного обеспечения ознаменовало эпоху, в которой эффективность практик программирования приобрела большую важность по сравнению с производительностью кода, а Ларри Уолл, в свою очередь, не преминул подтвердить данный тезис на практике. Предшественниками языка Perl были языки Awk (представленный в 1977 году) и Unix shell sh (представленный в 1978 году), причем сам этот язык опередил появление ядра Linux (первая версия которого была представлена в 1991 году) на несколько лет. (Обратитесь к странице, расположенной по адресу http://history.perl.org/PerlTimeline.html, если вас интересует шкала времени с указанием различных этапов развития Unix/Linux и выдержками из соответствующих новостных групп.)

Версии 2 (1988 года) и 3 (1989 года) интерпретатора Perl были представлены общественности спустя непродолжительное время. Версия 4 интерпретатора Perl была выпущена лишь для того, чтобы четко увязать ее с каноническим руководством по программированию на языке Perl, изданным под названием «Программирование на Perl» (в оригинале «Programming Perl» или «Camel Book»).

Код версии 5 интерпретатора Perl (1994 года) был частично переписан и позволял использовать ряд новых сущностей, включая объекты и модули. Поддержка этих сущностей, в свою очередь, ознаменовала расцвет ресурса CPAN (Comprehensive Perl Archive Network), являющегося репозиторием компонентов интерпретатора и модулей Perl, в 1995 году. Хотя CPAN и является крайне полезным ресурсом, на нем несложно потеряться; на момент написания статьи на нем было опубликовано 157742 модуля, причем качество этих модулей значительно отличается и в некоторых случаях на нем крайне сложно найти модуль высокого качества для выполнения той или иной задачи. (Проект MetaCPAN и модуль Task::Kensho от Enlightened Perl Organisation были созданы специально для решения описанной проблемы.)

Версия 6 интерпретатора Perl находится в стадии активной разработки и на сегодняшний день рассматривается разработчиками как отдельная реализация языка программирования; обратная совместимость с классическим языком Perl не является их целью, тем не менее, в будущем Perl 6 должен стать «эталонной реализацией языка Perl». Изменения в язык вносятся главным образом с целью упорядочивания его синтаксиса. Разработка данной версии интерпретатора началась в 2000 году и продолжается до сих пор.

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

Совет: несмотря на то, что языки Sed и Awk являются предметно-ориентированными, вы сможете найти и код общего назначения на этих языках, обратившись к веб-сайту Rosetta Code!

Дополнительная информация: неофициальной расшифровкой названия языка Perl является «Practical Extraction and Reporting Language» («практический язык для извлечения данных и составления отчетов»), но Ларри Уолл предпочитает использовать свой шуточный вариант «Pathalogically Eclectic Rubbish Lister» («паталогически эклектичный перечислитель мусора»).

Код на Perl

Интерпретатор Perl поставляется в составе практически всех современных дистрибутивов Linux; если он не установлен в вашей системе, вам придется воспользоваться менеджером пакетов дистрибутива для его установки. А это код программы «Hello World»:

#!/usr/bin/perl -w
print "Hello Worldn";

Последовательность символов #! является последовательностью шебанг, сообщающей системе о том, что остальную часть строки следует считать путем к исполняемому файлу интерпретатора, причем при запуске интерпретатора нужно передать ему путь к открытому файлу сценария. Таким образом, при запуске сценария hello.pl первая его строка сообщает системе о том, что следует исполнить бинарный файл /usr/bin/perl и передать ему путь к файлу сценария hello.pl для интерпретации. Интерпретаторы языков сценариев обычно игнорируют последовательность символов шебанг либо из-за того, что символ # является индикатором строки комментария, либо из-за того, что эта последовательность символов известна интерпретатору и игнорируется им.

Параметр -w позволяет активировать механизм вывода сообщений об ошибках, который является весьма полезным на практике. (Вы также можете добавить в свой сценарий строку use strict; сразу же после первой строки для того, чтобы заранее получать информацию об определенных ошибках времени компиляции и исполнения.) Вы наверняка заметили, что все инструкции языка Perl заканчиваются символом ;. Теперь следует сделать файл сценария исполняемым и запустить его с помощью команды ./hello.pl.

А это гораздо более интересный код, отображающий множество Мандельброта в окне вашего эмулятора терминала:

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

Циклы for используют по три значения: for (начальное_значение; конечное_значение; приращение) {..}. Вы можете как увеличивать, так и уменьшать значение переменной в рамках цикла for, кроме того, никто не запрещает вам использовать вложенные циклы таким же образом, как в примере выше.

Использованный в коде выше оператор ? является сокращенным вариантом условной инструкции it-then-else. В том случае, если функция возвращает истинное логическое значение true (обозначающее, что значение находится за пределами множества), мы выводим символ пробела; в противном случае мы выводим символ звездочки.

Исполнение сценария на языке Perl

Python

Язык Python является чуть ли не ровесником языка Perl; Гвидо ван Россум (великодушный пожизненный диктатор сообщества разработчиков Python) начал работу над реализацией первой версии его интерпретатора под номером 0.9.0 в 1989 году и выпустил ее в 1991 году. На тот момент интерпретатор уже позволял использовать классы и механизм их наследования, а также функции, основные типы данных и модули. В 1994 году наконец была выпущена версия 1.0 данного интерпретатора, поддерживающая функции lambda, map, filter и reduce, хорошо знакомые разработчикам, использующим язык Lisp. Изначально логичный и простой синтаксис языка Python прорабатывался главным образом с целью привлечения к разработке программных продуктов не-программистов; на сегодняшний день он все еще дорабатывается с целью достижения максимальной логичности и простоты синтаксических конструкций, но не-программисты уже не рассматриваются в качестве его целевой аудитории.

Функции языка Python могут свободно расширяться, причем модули могут разрабатываться как с использованием языка Python, так и с использованием языка C; это означает, что коллеги Гвидо ван Россума, привыкшие к языку C, могли начинать работу с новым для них языком Python без дополнительной подготовки. Одна из целей автора языка заключалась в создании своеобразного моста между языком командной оболочки и языком C; другими словами, он создавал второй язык для разработчиков, постоянно использующих языки C и C++, который мог бы применяться в тех случаях, когда использование языка C или C++ нецелесообразно. В основу языка Python были положены идеи, заимствованные из таких языков программирования, как ABC (язык программирования для не-программистов), C, Bash, Lisp, Perl и Java.

В версию интерпретатора 2.0, выпущенную в 2000 году, была добавлена абстракция списков, предназначенная для упрощения методики создания и обработки различных списков и основывающаяся на идее, заимствованной из функциональных языков программирования. Версия интерпретатора 3.0 была выпущена в 2008 году и содержала огромное количество изменений, направленных главным образом на сокращение избыточности, накопленной в процессе разработки предыдущих версий интерпретатора Python (с неизбежным нарушением обратной совместимости). В отличие от подхода разработчиков интерпретатора Perl, у разработчиков версии 3.0 интерпретатора Python был следующий девиз: «Должен существовать один, а еще лучше единственный очевидный способ выполнения конкретной задачи». При этом была сохранена мультипарадигменность, присущая языкам сценариев общего назначения; в результате вы можете использовать язык Python для написания объектно-ориентированного, структурного, функционального кода и так далее. Подобная гибкость хотя и является полезной, но нередко также становится причиной возникновения сложностей при разборе кода других людей особенно начинающими разработчиками.

Код на языке Python является компактным (вам придется написать меньше строк кода для выполнения той же работы по сравнению, к примеру, с языком Java) и хорошо читаемым, исполняется достаточно быстро, позволяет вести быструю разработку программ (как и все остальные языки сценариев), позволяет применять приемы объектно-ориентированного программирования и может ложиться в основу программных решений для широкого спектра областей применения. Однако, он все же исполняется медленнее, чем машинный код, полученный в результате использования компилируемых языков программирования, и, несмотря на благотворное воздействие некоторых оптимизаций, не используется в веб-приложениях на стороне клиента. Появление огромного количества библиотек для данного языка в последние годы значительно повысило его популярность; он всегда был доступен для начинающих разработчиков, а сейчас стал актуален и для профессионалов.

Прекрасное интервью Гвидо ван Россума об истоках языка программирования Python доступно по ссылке www.artima.com/intv/pythonP.html.

Код на языке Python

В вашей системе наверняка также установлен интерпретатор языка Python (если это не так, вам следует воспользоваться менеджером пакетов вашего дистрибутива для его установки). А это код программы «Hello World»:

#!/usr/bin/python
print "Hello World"

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

А это код на языке Python, визуализирующий множество Мандельброта:

Как и в случае языка программирования Perl, мы импортируем библиотеку (в данном случае это библиотека math) для работы с комплексными числами. В Python x + yi является аналогом x + y * 1j.

Функции обозначаются с помощью ключевого слова def. В рамках циклов for используется ключевое слово range. В рамках диапазонов, объявляемых с помощью ключевого слова ranage, должны использоваться целочисленные значения, но, как и в данном случае, при необходимости использования цикла с нецелочисленными значениями, вы можете умножить целочисленное значение из диапазона на нецелочисленное и использовать результат в рамках цикла.

Так как интерпретатор Python автоматически добавляет символ новой строки при использовании функции print, для получения вывода без символов новой строки нам придется использовать метод объекта строки join. Обратите внимание на циклы for в рамках инструкции print/join, а также методику использования условной инструкции if not ... else. В данном случае для сохранения результатов работы функции mandelbrot и объединения их в рамках списка используется абстракция списков.

Исполнение сценария на языке Python

JavaScript

Как известно, язык JavaScript был разработан Бренданом Эйхом, работавшим компании Netscape, за 10 дней в 1995 году. В то время компания Netscape предлагала клиентам серверное решение с переносимой версией виртуальной машины Java для исполнения апплетов на стороне сервера и нуждалась в более простом интерпретируемом и доступном для не-программистов языке программирования для взаимодействия с ними. Изначально этот язык носил имя LiveScript и был интегрирован в состав веб-браузера Netscape Navigator в 1995 году, но через некоторое время он был переименован в JavaScript одновременно с добавлением поддержки апплетов Java в этот веб-браузер, что, вероятно, являлось очередным маркетинговым ходом. Это интерпретируемый язык программирования для разработки сценариев, исполняющихся на стороне клиента непосредственно в веб-браузере.

Впоследствии специалисты компании Microsoft осуществили обратный инжениринг JavaScript с целью создания языка JScript, поддержка которого была добавлена в веб-браузер IE3 и веб-сервер IIS в 1996 году. Различия между двумя упомянутыми реализациями языка программирования затрудняли разработку интерактивных веб-сайтов, корректно работающих в обоих веб-браузерах, причем всю вину за это положение вещей начали возлагать именно на JavaScript. По этой причине компания Netscape связалась с организацией по международным стандартам ECMA, в результате чего в 1997 году был опубликован официальный стандарт ECMAScript. Язык JavaScript является лучшей известной реализацией данного стандарта; ActionScript 3 является еще одной его реализацией.

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

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

Однако, по мере роста популярности веб-приложений и в результате создания технологии Ajax (Asynchronous JavaScript and XML: механизм асинхронного взаимодействия с веб-сервером для обновления состояния элементов веб-страницы без ее полной перезагрузки, позволяющий повысить пользовательские качества веб-приложений), репутация JavaScript начала улучшаться, а сам язык стал все чаще использоваться профессионалами. Сегодня язык JavaScript активно используется для создания динамических веб-приложений и веб-страниц — без него практически не обойтись, если необходимо создать современную веб-страницу. Фреймворк Node.js наконец позволил использовать JavaScript не только на стороне клиента, но и на стороне сервера, а API HTML 5 позволяют размещать на страницах множество новых управляющих элементов, улучшая их пользовательские качества — разумеется, не в ущерб безопасности.

Код на языке JavaScript

Вы не сможете инициировать исполнение сценария на языке JavaScript с помощью команды в терминале; для того, чтобы испытать сценарий в работе вам придется открыть с помощью веб-браузера файл hello.html со следующим содержимым:

<!DOCTYPE HTML>
<html>
<head></head>
<body>

<script>
alert("Hello World")
document.write("Hello World")
</script>

</body>
</html>

Это минималистичная HTML-страница, предназначенная исключительно для исполнения сценария, код которого расположен в рамках тэга <script>. Фактически данный сценарий осуществляет двукратный вывод строки «Hello world»: вызов alert позволяет вывести всплывающее предупреждение (с автоматически добавленной кнопкой OK); вызов document.write позволяет вывести упомянутую строку в рамках тела документа HTML. Как и язык Python, язык JavaScript в общем случае не требует наличия символа точки с запятой после каждой инструкции (но позволяет использовать его), причем по поводу того, стоит ли использовать этот символ после каждой из инструкций или все же не стоит, не существует единого устоявшегося мнения. Вы также можете создать отдельный файл сценария с именем file.js и подключить его к HTML-странице:

А это код сценария для работы с множеством Мандельброта:

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

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

Как и в Python, в JavaScript переменные не должны иметь четко указанных типов, но при этом они должны объявляться с помощью ключевого слова var перед использованием (хотя это и не обязательно).

Циклы for работают практически так же, как и в двух описанных выше языках сценариев. Так как в JavaScript нет библиотеки для работы с комплексными числами, нам придется обрабатывать их действительные и мнимые части по отдельности. Инструкция document.write не позволяет выводить символы пробелов, поэтому вместо них в данном сценарии осуществляется вывод символов обратных кавычек.

Если вам хочется использовать все возможности HTML для вывода более привлекательной версии фрактала (не на основе ASCII-символов), вы также можете поискать соотвествующий код на веб-сайте Rosetta Code (rosettacode.org). И, как в случае с языками Perl и Python, существует огромное количество сетевых ресурсов с информацией, необходимой для изучения дополнительных возможностей JavaScript.

Процесс отладки сценариев на языке JavaScript может оказаться достаточно сложным из-за того, что сообщения об ошибках не выводятся в теле отображаемого документа; для отладки подобных сценариев может использоваться как ресурс JSLint (www.jslint.com), так и консоль JavaScript вашего веб-браузера

Bash

Bash значительно отличается от Perl, Python и JavaScript, так как является в первую очередь языком для управления задачами и исполнения команд. Но при этом он не перестает быть полноценным языком, который, тем не менее, не очень-то подходит для написания более чем одной-двух страниц кода.

Командная оболочка Bourne shell или sh была выпущена в 1977 году в составе UNIX Version 7 в качестве стандартного интерпретатора команд с поддержкой языка сценариев. Впоследствии она стала стандартной командной оболочкой UNIX и использовалась для выполнения широкого спектра задач, связанных с обслуживанием системы.

Проекту GNU, в рамках которого была начата разработка полностью свободного набора системного программного обеспечения, требовалась свободная полнофункциональная замена командной оболочки sh. В результате в 1989 году Брайн Фокс при финансовой поддержке Фонда Свободного Программного Обеспечения выпустил бета-версию командной оболочки Bash (Bourne-again shell). С того времени она стала стандартной командной оболочкой Linux (при этом такие командные оболочки, как tcsh и zsh также пользуются популярностью). Для того, чтобы узнать название используемой в данной момент командной оболочки вы можете просто выполнить команду echo $SHELL. Если в вашей системе используется какая-либо из альтернативных командных оболочек, вам будет достаточно выполнить команду /bin/bash для того, чтобы воспользоваться Bash.

Bash может исполнять отдельные инструкции, вводимые пользователем:

$ echo "Hello World"

Кроме того, она может исполнять файлы сценариев:

#!/bin/bash
echo "Hello World"

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

И это еще не все…

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

Статистические данные, собранные на ресурсах GitHub и StackOverflow в начале 2005 года, говорят о том, что языки JavaScript, Python, Ruby и PHP находятся в первой десятке популярных языков программирования, достойно конкурируя с такими популярными языками, как Java и C/C++. При изучении рынка вакансий также несложно прийти к аналогичным выводам. (Статистические данные доступны по ссылкам www.sitepoint.com/whats-best-programming-language-learn-2015 и www.codingdojo.com/blog/8-most-in-demand-programming-languages-of-2015.) Web 2.0 ассоциируется с развитием новых технологий, активным использованием языков сценариев, а также такими новыми языками, как Lua, чрезвычайно легким и адаптируемым встраиваемым языком программирования с динамической типизацией. Конечно же, несмотря на мнения некоторых экспертов, языки сценариев не захватят мир программирования, но по прошествии 30 лет они, безусловно, начали играть более важную роль и предоставили разработчикам возможность использования более гибких синтаксических конструкций.

Средняя оценка 1 при 1 голосовавших

Комментарии

First of all, there are some issues with your terminology. There is no such thing as a loosely typed language and the term scripting language is vague too, most commonly referring to so called dynamic programming languges.

There is weak typing vs. strong typing about how rigorously is distinguished between different types (i.e. if 1 + "2" yields 3 or an error).

And there is dynamic vs. static typing, which is about when type information is determined — while or before running.

So now, what is a dynamic language? A language that is interpreted instead of compiled? Surely not, since the way a language is run is never some inherent characteristic of the language, but a pure implementation detail. In fact, there can be interpreters and compilers for one-and-the-same language. There is GHC and GHCi for Haskell, even C has the Ch interpreter.

But then, what are dynamic languges? I’d like to define them through how one works with them.

In a dynamic language, you like to rapidly prototype your program and just get it work somehow. What you don’t want to do is formally specifying the behaviour of your programs, you just want it to behave like intended.

Thus if you write

foo = greatFunction(42)
foo.run()

in a scripting language, you’ll simply assume that there is some greatFunction taking a number that will returns some object you can run. You don’t prove this for the compiler in any way — no predetmined types, no IRunnable … . This automatically gets you in the domain of dynamic typing.

But there is type inference too. Type inference means that in a statically-typed language, the compiler does automatically figure out the types for you. The resulting code can be extremely concise but is still statically typed. Take for example

square list = map (x -> x * x) list

in Haskell. Haskell figures out all types involved here in advance. We have list being a list of numbers, map some function that applies some other function to any element of a list and square that produces a list of numbers from another list of numbers.

Nonetheless, the compiler can prove that everything works out in advance — the operations anything supports are formally specified. Hence, I’d never call Haskell a scripting language though it can reach similar levels of expressiveness (if not more!).

So all in all, scripting languages are dynamically typed because that allows you to prototype a running system without specifying, but assuming every single operation involved exists, which is what scripting languages are used for.

First of all, there are some issues with your terminology. There is no such thing as a loosely typed language and the term scripting language is vague too, most commonly referring to so called dynamic programming languges.

There is weak typing vs. strong typing about how rigorously is distinguished between different types (i.e. if 1 + "2" yields 3 or an error).

And there is dynamic vs. static typing, which is about when type information is determined — while or before running.

So now, what is a dynamic language? A language that is interpreted instead of compiled? Surely not, since the way a language is run is never some inherent characteristic of the language, but a pure implementation detail. In fact, there can be interpreters and compilers for one-and-the-same language. There is GHC and GHCi for Haskell, even C has the Ch interpreter.

But then, what are dynamic languges? I’d like to define them through how one works with them.

In a dynamic language, you like to rapidly prototype your program and just get it work somehow. What you don’t want to do is formally specifying the behaviour of your programs, you just want it to behave like intended.

Thus if you write

foo = greatFunction(42)
foo.run()

in a scripting language, you’ll simply assume that there is some greatFunction taking a number that will returns some object you can run. You don’t prove this for the compiler in any way — no predetmined types, no IRunnable … . This automatically gets you in the domain of dynamic typing.

But there is type inference too. Type inference means that in a statically-typed language, the compiler does automatically figure out the types for you. The resulting code can be extremely concise but is still statically typed. Take for example

square list = map (x -> x * x) list

in Haskell. Haskell figures out all types involved here in advance. We have list being a list of numbers, map some function that applies some other function to any element of a list and square that produces a list of numbers from another list of numbers.

Nonetheless, the compiler can prove that everything works out in advance — the operations anything supports are formally specified. Hence, I’d never call Haskell a scripting language though it can reach similar levels of expressiveness (if not more!).

So all in all, scripting languages are dynamically typed because that allows you to prototype a running system without specifying, but assuming every single operation involved exists, which is what scripting languages are used for.

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

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

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

Скриптовые языки применяются как для клиентского (JScript, VBScript),
так и для серверного (PHP) программирования веб-сайтов.

Имеются и универсальные скрипт-языки (Perl, Python, Ruby, Tcl).
Последние создавались для некоторых определённых целей, но со временем расширялись и применялись для всё более широкого круга задач
(например, Perl изначально создавалася как язык обработки текста, но затем был значительно усовершенствован).
Сейчас их уже называют не скриптовыми, а динамическими языками программирования, т.к.
они позволяют определять типы данных и осуществлять синтаксический анализ и компиляцию «на лету» — на этапе выполнения программы.
Такие языки удобны для быстрой разработки приложений.

Помимо упомянутых, к динамическим языкам относят также Smalltalk и JavaScript.
Некоторыми динамическими чертами обладает и Visual Basic.

Технологии Perl, SSI, PHP предназначены для разработки динамических веб-сайтов
и доступны на любой платформе.

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

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

Появился в: 1990 г.
Автор(ы): Гвидо ван Россум.
Испытал влияние: ABC, Modula-3, Lisp, Smalltalk, C, Java, Icon.
Повлиял на: Ruby, Boo, Groovy, ECMAScript.

Groovy — объектно-ориентированный язык программирования, разработанный для платформы Java
как дополнение к языку Java с возможностями Python, Ruby и Smalltalk.

Ruby — универсальный скрипт-язык для ООП, пришедшего на смену Perl + Python,
и сочетающего также достоинства языков Smalltalk, Eifel, Ada, Java.
Используется для быстрого программирования прототипов систем и в других областях.

История языка Ruby началась в 1993 году, когда Якихиро Мацумото (известный как “matz”)
взялся за реализацию собственного скриптового языка, который бы был таким же мощным и удобным, как Perl,
и более объектно-ориентированным, чем Python [концептуально повлияли также
языки искусственного интеллекта].

Первая общедоступная версия 0.95 увидела свет в 1995 году. После этого Ruby быстро получил широкое распространение в Японии —
это легко объяснимо происхождением языка и отсутствием языкового барьера между первыми пользователями Ruby и его создателем.
За период с 1995 по 2002 год в Японии вышло около двадцати книг о Ruby, и Ruby стал в этой стране более популярным языком, чем Python.
После 2000 года началось распространение Ruby по всему миру…

Сейчас, по данным компании Black Duck Software, Ruby — четвёртый по их количеству язык программирования после Java, C/C++ и C#…
Тем не менее, это говорит не о популярности Ruby, а об активном и заинтересованном сообществе разработчиков вокруг языка,
которые так страстно и трепетно относятся к последнему…

Интерпретируемый язык программирования высокого уровня Tcl ориентирован преимущественно на автоматизацию рутинных процессов ОС
и крупных программных систем, состоя из мощных команд, ориентированных на работу с абстрактными нетипизированными объектами.

Принципиальное отличие Tcl от командных языков ОС состоит в независимости от типа системы и, самое главное,
он позволяет создавать переносимые программы с графическим интерфейсом (GUI).

Страница обновлена 28.09.2022

Язык сценариев — это язык программирования, который интерпретируется, то есть переводится в машинный код при запуске кода, а не заранее. Языки сценариев часто используются для коротких сценариев над полными компьютерными программами. JavaScript, Python и Ruby — всё это примеры языков сценариев.

Вы можете быть удивлены, узнав, что за всю историю компьютеров было изобретено более 700 языков программирования . Это не так много, как у нас есть 6900 человеческих языков, но выучить любой новый язык — нелёгкое дело.

Язык сценариев (также известный как сценарии или сценарий) чётко определяется как серия команд, которые могут выполняться без необходимости компиляции . Хотя все языки сценариев являются языками программирования, не все языки программирования являются языками сценариев. PHP, Perl и Python — распространённые примеры языков сценариев.

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

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

Интерпретируемые и компилируемые языки программирования

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

В компилируемых языках программирования программа компилятора переводит код, написанный на языке программирования высокого уровня, на язык более низкого уровня, чтобы программа могла выполняться. Программы C или Java обычно должны быть сначала скомпилированы для запуска. Два хорошо известных компилятора — это Eclipse для Java и gcc для C и C ++.

Самый простой способ понять, как работает компилятор, — это подумать о различных операционных системах. Например, программы Windows скомпилированы для работы на платформах Windows и поэтому несовместимы с Mac.

Серверные сценарии против клиентских сценариев

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

Языки сценариев на стороне сервера работают на веб-сервере. Когда клиент отправляет запрос, сервер отвечает, отправляя контент через HTTP. Напротив, языки сценариев на стороне клиента работают на стороне клиента — в их веб-браузерах.

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

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

Примеры языков сценариев на стороне сервера

Ниже приведены примеры языков сценариев на стороне сервера.

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

Ниже приведены примеры языков сценариев на стороне клиента.

Приложения языков сценариев

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

Языки сценариев также используются во многих играх и мультимедиа. Например, в модах Minecraft используется Java, чтобы пользователи могли создавать собственные миры и предметы в игре. Кроме того, Second Life , Trainz и Wesnoth позволяют пользователям создавать расширения для игр.

Подобно расширениям, используемым в играх, расширения в других программах, таких как расширения браузера Google Chrome, все запускаются с использованием языков сценариев.

Плюсы и минусы языков сценариев

Плюсы

Использование языков сценариев даёт много преимуществ перед другими языками программирования. Они с открытым исходным кодом. Это позволяет пользователям со всего мира присоединиться к процессу улучшения. Другие плюсы включают:

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

Минусы

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

Вывод

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