Отсутствие в языке деления переменных на типы упрощает соединение компонентов между собой. Нет априорных ограничений на то, каким образом может использоваться тот или иной элемент, а все компоненты значения представляются в едином формате. Таким образом, компонент или значение могут быть использованы в любой ситуации; будучи спроектированы для одних способов применения, они могут оказаться задействованы совершенно иными, о которых их создатель никогда не помышлял. Например, в UNIX – оболочках работа любой программы – фильтра включает чтение данных из входного потока и запись их в выходной поток. Любые две такие программы могут быть связаны путем назначения выходного потока одной в качестве входного потока другой. Следующая команда оболочки представляет систему из трех фильтров, подсчитывающую в выделенном фрагменте текста строки, содержащие слово “scipting”:
Select | grep scripting | WC
Программа select считывает текст, выделенный в данный момент на экране, и выводит его свои выходной поток; фильтр grep считывает входной поток и пропускает на выход строки, содержащие слово “scripting”; а программа wc подсчитывает число строк в своем потоке. Любой из подобных компонентов может найти применение во множестве различных ситуации, решая каждый раз иную общую задачу. Сильная типизация языков программирования системного уровня затрудняет повторное использование кода. Она поощряет программистов к созданию большого количества несовместимых друг с другом интерфейсов, каждый из которых требует применение объектов своего типа. Компилятор не позволяет объектам других типов взаимодействовать с этим интерфейсом, не смотря на то, что результат, мог бы оказаться и весьма полезным. Таким образом, чтобы использовать новый объект с существующем интерфейсом, программисту приходится писать “переходник”, преобразующий объект к типу, на который рассчитан интерфейс. А применение “переходника” требует, в свою очередь, перекомпиляции части или даже всего приложения целиком. Доминирующий в настоящее время способ распространения ПО в виде двоичных файлов делает этот подход невозможным.
Чтобы оценить преимущества бес типового языка программирования, рассмотрим следующий пример на языке Tcl:
Button .b –text Hello! -font {Times 16} – command {puts hello} .
Эта команда создает на экране новую кнопку с надписью на ней Hello! шрифтом Times 16 пунктов, при нажатии, на которую выводится короткое сообщение hello . В одной строке здесь уместилось шесть элементов различных типов: название команды (button), название кнопки (. b), идентификаторы атрибутов (-text, -font, -command), простые строки (Hello! hello), спецификация шрифта (Times 16), состоящая из названия начертания (Times) и размера в пунктах (16), а также целый Tcl-сценарий (putshello). Все элементы представляются единообразно – в виде строк. В данном примере атрибуты могли быть перечислены в произвольном порядке, а неупомянутым атрибутам (их насчитывается более 20) будут присвоены значения по умолчанию.
В случае реализации на Java тот же самый пример потребовал бы семи строк кода, составляющих два метода. Для С++ с использованием библиотеки MicrosoftFoundationClasses (MFC) масштабы увеличились примерно до 25 строк кода, образующих три процедуры. Один только выбор шрифта требует нескольких обращении к функциямMFC
Cfont *fontPtr=new Cront ();
fontPtr->Crete Font (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 существенные характеристики шрифта (начертание Times и кегль 16 пунктов) могут быть указаны непосредственно без каких-либо объявлений или преобразовании. Более того, TCL позволяет описать и поведение кнопки непосредственно в теле создающей ее команды, тогда как в С++ или Java для этого необходим отдельный метод.
Языки описания сценариев на подъеме
Языки описания сценариев существуют уже длительное время, однако, в последние годы в результате сочетания ряда факторов существенно повысилась их актуальность. Наиболее важный из этих факторов – направленность в сторону приложении, собираемых из готовых компонентов, В качестве трех иллюстрации его проявления можно назвать графические интерфейсы пользователя, Internet и компонентные инфраструктуры разработки.
7. Графические интерфейсы пользователя
Первые графические интерфейсы пользователя появились в начале 1980 г. и приобрели широкое распространение к концу десятилетия. Сегодня на описание этой части программы во многих проектах уходит более половины всех усилии разработчиков. GUI по своей природе является составной компонентной системой. Цель его создания состоит не в реализации новых функциональных возможностей, а в том, чтобы наладить связи между графическими элементами управления и функциями внутренних частей приложения.
Некоторые из систем снабжены очень удобными графическими средствами для построения экранов, которые скрывают сложности лежащего в основе языка, однако, как только возникает необходимость в написании дополнительного кода, например, чтобы расширить спектр вариантов поведения элементов интерфейса, у разработчика сразу возникают трудности. Все лучшие среды ускоренной разработки основаны на языках описания сценариев: VisualBasic, HyperCard, TCL/TK.
Развитие и рост популярности Internet также способствовали распространению языков описания сценариев. Сама сеть является не чем иным, как средством связи систем. Она не создает никаких новых данных и не занимается их обработкой; все, что она делает- обеспечивает легкий доступ к огромному множеству существующих объектов. Идеальным языком программирования для решения большинства связанных с сетью задач мог бы стать тот, который лучше организует совместную работу всех связанных компонентов, т. е. язык описания сценария. Так, для написания сеть сценариев широко употребляется язык Perl, а среди разработчиков WEB-страниц популярен JavaScript.
8. Компонентные инфраструктуры
Третий пример применения языков описания сценариев - компонентные инфраструктуры, такие как ActiveX, JavaBeans. Хотя языки программирования системного уровня с успехом используются для создания компонентов, задачи сборки из них приложений удобнее решаются при помощи сценариев. Без хорошего языка описания сценариев, предназначенного для манипулирования компонентами инфраструктуры, теряется значительная часть ее достоинств. Этим можно объяснить отчасти, почему компонентные инфраструктуры добились большей популярности в мире ПК, где существует такое удобное связующее средство, как VisualBasic, нежели на других платформах, таких как Unix/Cobra, компонентные инфраструктуры, для которых лишены языков описания сценариев.
9. Технология сценариев
Еще одна причина роста популярности языков описания сценариев – развитие их технологии. Такие современные представители этой категории, как TCL, Perl мало, чем напоминают своих далеких предшественников вроде JCL. Так, JCL не предусматривал даже простейших форм интерактивного взаимодействия, а ранние UNIX – оболочки не поддерживали процедур. Данная технология еще и сегодня остается относительно незрелой. Например, VisualBasic не является в полном смысле языком описания сценариев. Первоначально он был разработан в качестве упрощенного языка системного уровня, а затем – модифицирован так, чтобы его было удобнее применять к описанию сценариев. Таким образом, у будущих языков подобного рода есть большой простор для совершенствования.
Кроме того, технология сценариев много выиграла от повышения производительности компьютерного оборудования. Еще не так давно, чтобы добиться приемлемой скорости работы приложения любого уровня сложности, необходимо было обращаться к языкам системного уровня. В некоторых случаях даже их эффективность оказывалась недостаточной и программу приходилось писать на ассемблере. Современные машины работают в 100 – 500 раз быстрее компьютеров 80 – х годов, и их производительность продолжает удваиваться примерно каждые 18 месяцев. Сегодня целый ряд приложений может быть реализован на языках описания сценариев при тем не менее великолепной производительности. Например, TCL – сценарии позволяет манипулировать тысячами объектов при сохранении хорошего уровня интерактивности. По мере того как компьютеры будут становиться быстрее и быстрее, применение языков описания сценариев будет становиться привлекательным для реализации все более и более масштабных приложений.
10. Другие языки
Существует огромное количество атрибутов, помимо степени строгости контроля типов или уровня языка, и есть очень много интересных примеров, которые не могут быть однозначно отнесены к одной из двух рассмотренных нами категории. Например, семейство Lisp занимает некоторое промежуточное положение, обладая атрибутами языков описания сценариев и языков программирования системного уровня. В Lisp впервые были реализованы такие концепции, как интерпретация и динамический контроль типов, которые широко используются в современных языках описания сценариев, А также автоматическое управление хранением и интегрированные среды разработки, применяемые в языках обеих категории.
11. Заключение
Языки описания сценариев основаны на несколько другом наборе компромиссов, чем языки системного уровня. В них скорость исполнения и строгость контроля типов ставятся в шкале приоритетов на более низкое место, но зато выше цениться производительность труда программиста и повторное использование. Это соотношение ценностей оказывается все более оправданным по мере того, как компьютеры становятся быстродействующими и менее дорогими, чего нельзя сказать о программистах. Языки системного программирования хорошо подходят для создания компонентов, где основная сложность заключена в реализации алгоритмов и структур данных, тогда как языки описания сценариев лучше приспособлены для построения приложении из готовых компонентов, где сложность состоит в налаживании межкомпонентных связей. Задачи последнего рода получают все большее распространение, так что роль парадигмы сценариев будет возрастать и в будущем веке.