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

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

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

можно в принципе получать автоматически (конечно, при определенных

ограничениях на теории и частичные описания объектов). Например, если задана

"теория" языка Ада в виде совокупности правил БНФ, то достаточно написать

текст конкретной программы, чтобы параметрический синтаксический анализатор

был в состоянии по этой теории и фактам (конкретной последовательности

литер) построить дерево вывода этой программы в синтаксисе Ады - полное

описание конкретного информащионного объекта (модели, конструкции),

удовлетворяющее теории и дополнительным условиям.

Это возможно потому, что язык БНФ разрешим в том смысле, что существует

алгоритм построения дерева разбора для любого входного текста и любого

синтаксиса, написанного на БНФ.

При этом деревьев разбора может быть несколько и даже бесконечно много

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

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

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

соответствующий сеточный метод как разрешающий алгоритм рассматриваемой

теории. Однако здесь, как известно, не существует общего разрешающего

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

краевых условиях.

("р") Когда модель построена, бывает интересно узнать ее свойства

(обычно неизвестные до построения). Другими словами, на модели приходится

решать конкретные классы задач. В случае дерева разбора такие классы задач

возникают, например, при контекстном анализе программы и синтезе объектного

кода (требуется найти объявления для выбранных идентификаторов программы,

проверить соответствие числа формальных и фактических параметров при вызове

процедуры и т.п.). Задачи этих классов можно при определенных условиях

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

задачи (и даже не строя модель целиком).

("с") Один из способов состоит в том, что еще при описании теории

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

том, что одни компоненты могут быть непосредственно вычислены по другим (с

помощью процедур, явно заданных на обычном ЯП, например, на Фортране или

Паскале). Если теперь рассматривать только задачи вычисления компонент

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

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

решающие поставленную задачу при любых возможных аргументах. Таким образом

появляется возможность настраиваться в конкретной модели на конкретный класс

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

(выделяющих конкретную задачу из этого класса).

[В сущности, таким планировщиком "расчетных цепочек" служит и

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

по дереву вывода из "элементарных" заготовок, поставляемых семантическими

процедурами-трансдукторами. Но при этом решается очень узкий класс задач -

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

данные.]

20.3.3. Абстракция от программы (в концептуальном и реляционном

программировании)

Классический пример "концептуального программирования" - решение

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

треугольников (сторонами, углами, периметром, площадью) - им соответствуют

явные процедуры; моделью - треугольник с соответствующими атрибутами;

задачей - запрос на вычисление, например, площади по заданным сторонам (при

этом указываются не значения сторон, а только их имена). Планировщик готовит

расчетную цепочку. Остается последняя конкретизация - можно задавать

значения сторон и получать соответствующие значения площади после выполнения

расчетной цепочки.

Указанный подход реализован в отечественных системах ПРИЗ и СПОРА (ЯП

соответственно Утопист и Декарт)[49,50].

В инструментальном режиме работы этих систем программисты-конструкторы

строят модель-конструкцию (выписывают необходимые соотношения вычислимости и

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

возможность работать в функциональном режиме в рамках созданной модели-

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

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

результатов, а затем после работы планировщика эксплуатирует полученную

расчетную цепочку.

Языки Утопист и Декарт обеспечивают абстракцию от программы и от

задачи, но не от модели. Модель (точнее ее процедуры) приходится явно

программировать.

Другой подход предлагает реляционное программирование, о котором шла

речь в разделе 16. Наиболее известный язык этого класса - Пролог. К этому же

классу относится отечественный Реляп. В них не требуется задавать

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

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

ответа на запрос-задачу. Таким образом, обеспечивается абстракция и от

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

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

В самом начале книги в качестве одного из источников сложности

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

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

а не действий. Другими словами, "мир" обычного компьютера не содержит знаний

о ПО (ее теории). Именно это обстоятельство не позволяет указывать цели и

контролировать их достижение.

Концептуальное программирование в рамках конкретной модели позволяет

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

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

вперед по сравнению с традиционными ЯП как с точки зрения абстракции-

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

это за счет представления в компьютере знаний о проблемной области -

фрагмента внешнего мира - в виде (разрешимой за счет планировщика и

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

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

компьютере знаний о ПО (фрагментов ее теории), а выбранный уровень

абстракции и необходимость явно программировать модель определяются в

основном реализационными соображениями (стремлением к снижению

ресурсоемкости программ).

Реляционное программирование "чище" в идейном отношении. Его ключевой

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

теории в компьютере - никакого программирования! Задачи решаются

автоматически единым разрешающим алгоритмом. Проблемами ресурсоемкости

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

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

традиционном ЯП. Даже если это неприемлемо, реляционная программа

оказывается исключительно полезной как "исполняемая спецификация"

традиционной реализации.

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

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

области ЯП основной была абстракция от компьютера, то в ближайшей

перспективе основной станет абстракция от программы (ее можно назвать и

абстракцией от реализации).

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

языками программирования. Скорее это разрешимые языки представления знаний.

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

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

20.3.4. Социальный аспект ЯП

Очевидно. что далеко не все абстракции из п.20.3.3 обеспечены

соответствующими языковыми конструктами (и, по-видимому, некоторые никогда

не будут обеспечены); но приведенный спектр абстракций дает возможность

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

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

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

оптимального уровня абстракции в соответствии с требованиями к ЯП.

Приведенный на рис. 20.3.1 перечень абстракций показывает важность

социального аспекта ЯП. Например, абстрагироваться от компьютера - дело

творцов ЯП, а вот средства конкретизации обеспечивают реализаторы

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

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

внутренних свойств, причем это может касаться важнейших для пользователя

абстракций.

Свойства ЯП как социального явления (точнее артефакта) подчеркивает

также уже отмеченная изменчивость оценки ЯП, связанная с внешней по

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

накоплением реализаций и программ, появлением хороших учебников, развитием

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

Упомянутую абстракцию от программы (от ее реализации, а не

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

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

возможности) знать программу для желающего ее развить.

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

принципом защиты авторского права - ЯП должен способствовать защите

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

качества предоставляемых услуг. Этот принцип мы отмечали еще в связи с Адой,

но свое почти идеальное воплощение он нашел в объектно-ориентированном

программировании.

20.3.5. Стандартизация ЯП

Если освоение перспективных абстракций отражает стремление творцов ЯП

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

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

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

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

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

Таким образом, в идеале указанные две тенденции взаимно дополняют и

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

здорового радикализма, то вторую - основным источником здорового

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

изолированно, каждая вносит свой вклад в современное развитие ЯП.

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

и эмоционально ближе первая из отмеченных тенденций. Вторая для своей

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

несравненно более высокой квалификации (и даже жизненного опыта). Поэтому и

по ряду других причин стандартизация в области ЯП пока значительно отстает

от потребностей практики как в мире, так и особенно в СССР. С другой

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

научной проблематикой, специфическими методами и техническими средствами,

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

Среди последних - международные стандарты Фортрана, Паскаля, Ады, проекты

стандартов Си, Бейсика, перспективного Фортрана, расширенного Паскаля и др.

[51].

В среде программистов со стандартизацией ЯП связана целая серия

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

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

устранение вносят уже упоминавшиеся публикации [30-32].

Заключение.

Подведем итоги. Во-первых, мы смотрели на ЯП с нескольких различных

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

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

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

авторской. Таковы принцип цельности; принцип РОРИУС; концепция уникальности

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

ее решения; концепция регламентированного доступа (инкапсуляция); принцип

реальности абстракций; принцип целостности объектов; концепция внутренней

дисциплины доступа к разделяемым ресурсам; концепции единой модели числовых

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

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