В.Ш. Кауфман - Языки программирования - концепции и принципы (1990) (1160787), страница 81

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 81)

Апл и более современные Визикалк, Лого и др.). Промежуточный вариант -

программу в процессе ее исполнения может изменять лишь сама программа (но не

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

Лисп, Инф и др.).

Связь концепции диалога с общей концепцией ЯП заслуживает

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

планирования поведения исполнителя в чистом виде не обязана предполагать

диалога (создатель программы вполне может и отсутствовать в период ее

исполнения - и это типичный для ЯП случай, тем более для ЯП индустриального

программирования). Другими словами, концепция ЯП в общем случае не

предполагает обратной связи исполнителя с создателем программы в процессе ее

рабочего исполнения.

Концепция диалога обязана предполагать такую связь и поэтому в общем

случае требует специфических выразительных средств, отличающихся от средств

планирования (краткостью, менее жестким контролем, ориентацией на

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

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

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

20.2.2. Недостатки традиционной классификации.

Между тем удовлетворительной классификации живых ЯП не существует. Тот

или иной ярлык, присваиваемый ЯП в программистском фольклоре или литературе,

в лучшем случае отражает лишь некоторые его характерные свойства. К тому же

с развитием самого ЯП, сферы его применения, контингента пользователей,

методов программирования, критериев качества программ и т.п. относительное

положение ЯП, его оценка может существенно измениться.

Например, Фортран начинался как язык высокого уровня для научно-

технических расчетов. Однако его первый международный стандарт (ему

соответствует отечественный ГОСТ 23056-78) выделяется уже скорее не особой

пригодностью для создания расчетных программ, сколько пригодностью для

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

практически произвольного назначения. Так что если хотите, чтобы Ваша

программа работала на любой машине и практически в любой операционной среде,

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

например, в [44].

Аналогична судьба и других классических языков. Их современная оценка

зависит, скорее, не от технических характеристик, а от социальных

(распространенность и качество реализаций, наличие устойчивого контингента

пользователей в определенной области знаний, объем парка эксплуатируемых

программ и т.п.).

Так, Бейсик и Паскаль, появившись как учебные ЯП с весьма ограниченной

областью серьезных применений, стали, подобно Фортрану, практически

универсальными ЯП на персональных компьютерах (еще одно подтверждение роли

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

дальше действует принцип чайника).

20.2.3. Принцип инерции программной среды

К сожалению, системы программирования, поддерживающие разные ЯП, как

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

программы на одном ЯП, часть на другом, или воспользоваться программой,

написанной на другом ЯП. Если бы эта "проблема модульной совместимости"

различных ЯП была решена, то только тогда технические характеристики ЯП

приобрели бы существенный вес при выборе конкретного ЯП для решения

конкретной задачи.

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

задачи и ЯП как инструмента ее изолированного решения, а тот язык и та

среда, с помощью которых обеспечены программные услуги, которыми необходимо

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

программной) среды: развивать среду лучше всего ее "родными" средствами. Еще

одна модификация принципа чайника (или его следствие).

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

инструментального ЯП подчиняется принципу инерции среды и как

самостоятельная проблема перед рядовым программистом обычно не стоит. К

сожалению, многие учебники программирования не учитывают принципа инерции и

по существу вводят читателей в заблуждение, уделяя излишнее внимание

технической стороне проблемной ориентации ЯП.

20.2.4. Заповеди программиста

Сформулируем в краткой форме ответы на основные вопросы об оценке,

выборе, использовании и создании ЯП.

1. Выбирай не столько базовый ЯП, сколько базовую операционную среду (с

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

2. На основе выбранного базового ЯП создавай свой ПОЯ для каждой

значимой задачи с учетом выбранной технологии.

3. ЯП тем лучше, чем дешевле с его помощью оказывать программные

услуги.

4. Минимальное ядро ЯП плюс сколь угодно сложные проблемно-

ориентированные языковые модули - это разумный компромисс сундука с

чемоданчиком.

20.3. Тенденции развития ЯП

20.3.1. Перспективные абстракции

Переходя от классификации современных ЯП к тенденциям их развития,

прежде всего отметим аналог принципа чайника: область ЯП в целом, с одной

стороны, стремительно развивается, но, с другой стороны, остается весьма

консервативной. Первое касается в основном теоретических исследований и

экспериментов в области языкотворчества, второе - практики массового

программирования. Естественная инерция носителей традиционных ЯП, трудные

проблемы совместимости и переноса программных изделий, недостоверность

оценок выгоды от применения новых ЯП, высокая степень риска от неправильной

оценки перспективности ЯП при многомиллионных затратах на комплексное

освоение ЯП создают на пути широкого внедрения новых ЯП порог, преодолеть

который за последние годы удалось лишь нескольким языкам (Си, Модула-2,

Пролог, Фортран-77, Ада). Программисты в основном продолжают пользоваться

традиционными языками (Бейсик, Паскаль, Фортран, Кобол, Лисп) и их

диалектами, учитывающими новые возможности аппаратуры (диалог, графику,

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

типизацию, наследование и др.).

Поэтому говоря о тенденциях развития ЯП, уделим основное внимание

достаточно отработанным идеям и концепциям, уже вошедшим в практику

программирования, но, возможно, еще не завоевавшим всеобщего признания. С

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

непосредственно воспринимаемых программистом (внешних, технологических

свойств ЯП) и тенденции, касающиеся внутренней проблематики ЯП, в

значительной степени скрытых от программиста (внутренних, авторских).

Из внешних тенденций выделим освоение перспективных абстракций, а из

внутренних - стандартизацию ЯП.

Среди других заслуживающих внимания тенденций отметим освоение новых

этапов жизненного цикла программных изделий. С этой точки зрения характерен

язык проектирования программ SDL/PLUS [45]. В нем самое для нас интересное -

концепция непрерывного перехода от спецификации программы к ее реализации, а

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

Подчеркнем, что ЯП в своем развитии отражают (с некоторым

запаздыванием) квинтэссенцию современной философии программирования и в этом

качестве воспринимают все его фундаментальные концепции.

Казалось бы, естественным развитием ЯП было бы освоение новых

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

Однако пока этот аспект не дал ничего особо интересного для ЯП. Возможно,

сказывается отмеченное выше различие концепций ЯП и диалога, где названные

средства стремительно осваиваются.

Некоторые тенденции развития ЯП может подсказать следующий перечень

характерных примеров абстракции-конкретизации рис.. В его первой колонке

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

в второй колонке, и средства конкретизации, указанного в третьей колонке.

Сначала перечислены хорошо освоенные абстракции, затем - менее привычные,

наконец - перспективные.

АСПЕКТ СРЕДСТВО АБСТРАКЦИИ СРЕДСТВО КОНКРЕТИЗАЦИИ

----- Освоенные абстракции -----

а) размещение имя загрузчик, управление

представлением

б) исполнение процедура вызов, специализатор

в) порождение родовые объекты, макровызов, настройка,

макросы макрогенератор

г) компьютер ЯП транслятор

(виртуальная машина) (эмулятор)

---- Менее привычные абстракции -----

д) контекст пакет, модуль указатель контекста

ж) реализация спецификация связывание (по именам)

з) представление абстрактные ресурсы, спецификация представления

типы данных пакет, модуль

(АТД, в частности)

и) именование образец, условие ассоциативный поиск,

конкретизация образца

к) исключения нормальные сегменты аварийные сегменты

л) взаимодействие последовательные сигналы, семафоры,

процессов сегменты рандеву, каналы

м) ЯП псевдокод программист, конвертор

н) изменения слой (по Фуксману) слой изменений

программы

----- Перспективные абстракции -------

о) проблемная информатика творец прикладной

область теории

п) информационный теория, система факты, база данных,

объект, модель соотношений, база дополнительные соотношения

знаний

р) задача, (вычислительная) имена аргументов

запрос модель и результатов

с) программа задача значения аргументов

Рис. 20.3.1

Поясним некоторые термины.

(и") Абстракция от (прямого) именования обеспечивается использованием

образцов (вспомним модель МТ). Конкретизация (связь "косвенного имени" со

значением) осуществляется поиском подходящего образца (если фиксировано

значение) или подходящего значения (если фиксирован образец). Такой поиск

называют ассоциативным. Он широко используется в современных ЯП [46,47 и

др.].

("м") Конверторами называют программы, переводящие с одного ЯП

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

называемых "структурных" расширений стандартных ЯП (Фортрана, ПЛ/1, Кобола).

Они позволяют писать программу на псевдокоде, в значительной степени

отвлекаясь от особенностей конкретного ЯП, а затем автоматически или

полуавтоматически получать программу на стандартном ЯП.

("н") Подход к абстракции от потенциальных изменений программы (в

процессе ее разработки) впервые сформулирован А.Л.Фуксманом в его концепции

"расслоенного программирования"[48]. Программа строится как иерархия

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

программой услуг. При этом последующие слои строятся как перечни изменений

предыдущих слоев. Так что при создании (рассмотрении, изучении) очередного

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

реализующих более развитые услуги (функции). Особенно важно, что каждый

очередной слой работоспособен без последующих. Концепция расслоенного

программирования поддержана ЯП АКТ[48]. Близка к ней по замыслу (и эффекту)

и так называемая инкрементная компиляция (в сочетании с развитыми средствами

поддержки проектов), реализованная в известной системе R1000 [хотя основная

исходная мотивировка инкрементной компиляции - экономия перекомпиляций, а не

рациональная структура программы). Концепцию расслоенного программирования

полезно сопоставить с современной концепцией наследования в ЯП, наиболее

полно воплощенной в объектно-ориентированных ЯП.

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

С.С.Лаврова.

("о") Творец (прикладной) теории конкретной проблемной области

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

представляет знание о синтаксисе языка Ада в виде правил БНФ. Это знание

состоит из фактов, касающихся единичных объектов, и общих правил

(соотношений), касающихся целых классов объектов. Примеры фактов : А -

буква, 7 - цифра. Примеры соотношений : присваивание = левая_часть

правая_часть. Работа творца теории существенно неформальная, поэтому разумно

говорить лишь о частичной ее автоматизации.

Однако если теория записана на подходящем языке представления знаний,

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

работы.

("п") Во-первых, можно добавить факты и соотношения, характеризующие

конкретный объект, соответствующий теории (в логике такой объект называется

моделью, в технике - конструкцией). После этого полное описание объекта

Характеристики

Список файлов книги