Языки программирования концепции и принципы (стр. 7 )

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

1.17. Понятие о базовом языке

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

При таком взгляде создаваемая программа выступает как средст­во согласования этих моделей. Чем ближе исходные модели, тем проще программа. При идеальном исходном согласовании программа вырождается в прямое указание на одну из заранее заготовленных услуг (например, "распечатать файл", "взять производную", "вы­дать железнодорожный билет"). Мера рассогласованности моделей положена в основу известной "науки о программах" Холстеда.

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

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

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

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

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

1.18. Концептуальная схема рассмотрения ЯП

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

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

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

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

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

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

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

Итак, в каждом ЯП нас будет интересовать три аспекта: базис, аппарат развития (просто развитие), аппарат защиты (просто защи­та).

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

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

Некоторые компоненты базиса составляют аппарат развития ЯП, некоторые - аппарат защиты.

Об аппарате развития уже сказано. Добавим лишь, что будем различать развитие вверх - аппарат определения и использования новых абстракций, и развитие вниз - уточнение и переопределение компонент базиса или ранее определенных абстракций. Например, модуль-подпрограмма в Фортране - средство развития вверх. А средств развития вниз в Фортране нет (в отличие от Ады, Си или CDL).

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

Кроме базиса, развития и защиты будем рассматривать иногда другие особенности ЯП и, в частности, особенности эталонного исполнителя ЯП (так называемого языкового процессора) и архитектуру ЯП в целом. Например, для Фортрана исполнитель последовательный, для Рефала - циклический, а для Ады - параллельный.

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

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

2. Пример современного базового ЯП (модель А)

2.1. Общее представление о ЯП Ада

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

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

Мы исходим из принципа технологичности - всякий языковый конструкт предназначен для удовлетворения технологических по­требностей на определенных этапах жизненного цикла комплексного программного продукта. Этот принцип, с одной стороны, нацеливает на изучение важнейших потребностей в качестве "заказчиков" понятий и конструктов ЯП. С другой стороны, он требует понимать набор потребностей, обслуживаемых каждым понятием и (или) конструктом. Желательно видеть связь этих понятий с общей идеей абстракции-конкретизации. Будем подчеркивать эту связь, когда посчитаем существенной.

Когда говорят о технологических потребностях, всегда имеют в виду более или менее определенную ПО и технологию решения за­дач в этой области, в частности, технологию программирования. По­этому следует рассказать об особенностях той ПО, для которой создавался ЯП Ада.

Область, в которой реально применяется ЯП, отнюдь не всегда определяется намерениями его авторов (чаще всего она оказывается пустой!). Однако знание первоначальных замыслов авторов помогает понять особенности ЯП, взглянуть на язык как систему в какой-то мере согласованных решений, почувствовать то, что называют "духом" языка. Иначе язык покажется нагромождением условностей, которые очень трудно запомнить и применять.

Язык Ада создан в основном в 1975-1980 гг. в результате гранди­озного проекта, предпринятого МО США с целью разработать еди­ный ЯП для так называемых встроенных систем (т. е. систем управ­ления автоматизированными комплексами, работающими в реальном времени). Имелись в виду прежде всего бортовые системы управле­ния военными объектами (кораблями, самолетами, танками, ракета­ми, снарядами и т. п.). Поэтому решения, принятые авторами Ады, не следует считать универсальными. Их нужно воспринимать в кон­тексте особенностей выбранной ПО.