Непейвода Н.Н., Скопин И.Н. Основания программирования

Подождите немного. Документ загружается.

2.4. ПРИНЦИПИАЛЬНЫЕ ТРУДНОСТИ, СВЯЗАННЫЕ С СЕМАНТИКОЙ

105

Интерпретационная Теория алгоритмов

Теория автомат

ов

Функциона

льная Топология

Теория моделей

Алгебра (теория структур

)

Логическ

ая Теория моделей

Логика (теория доказательств)

Логика (неклассическая

)

рансляционная Теория графов

Теория автоматов

Формальные грамма

тики

Алгебраическ

ая Теория категорий

Теория моделей

Универсальная алг

ебра

Таблица 2.1. Семантики и требуемые знания

2. Приведите пример на используемом Вами языке программирования,

когда программа корректна при одних значениях прагматических па-

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

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

граммирования), а при других — успешно транслируется, но дает не-

верный результат.

3. Семантика каких понятий языка задается без ссылок на семантику дру-

гих понятий языка?

4. Возьмите какой-нибудь официальный стандарт описания языка (жела-

тельно

Алгола 68

[65] или

Ada

) и попытайтесь прочесть хотя бы три

страницы определений.

5. Приведите пример графически разных операторов с одинаковым аб-

страктным синтаксисом.

6. Реализуйте приведенные на рис. 2.11 схемы вызова процедуры при по-

мощи действий с указателями.

Глава 3

Стили программирования,

или программирование с

птичьего полета

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

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

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

либо наиболее характерных, случаях. Наша главная цель — дать рекомен-

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

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

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

упрямо применяют, несмотря на очевидные несообразности).

Стили программирования можно сопоставить со стилями одежды. Клас-

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

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

ношениях. Но представьте себе последствия появления в классической евро-

пейской одежде среди талибов или красных кхмеров!

Рассмотрению различных стилей программирования мешала иллюзия без-

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

и практику. До сих пор слово ‘универсальный’ используется в качестве хва-

лебного эпитета. Но универсальная система не всегда является удобным ин-

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

целесообразно, в частности, если задача достаточно простая и освоение ин-

струмента для ее решения потребует больше сил, чем само решение. Если

затем этой задачей придется заниматься дальше и дальше, затрата сил на под-

106

3.1. СТИЛИ ПРОГРАММИРОВАНИЯ

107

бор подходящего инструмента многократно окупится.

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

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

рованная или переросшая в результате «добавления новых возможностей»

рамки своей разумности. Поэтому необходимо настораживаться,встречая ре-

кламу очередной панацеи, очередного универсального средства. К тому же

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

А для решения нашей задачи необходимо сначала разобраться в самом

понятии стиля программирования.

§ 3.1. СТИЛИ ПРОГРАММИРОВАНИЯ

Поскольку стиль программирования — неформализуемое понятие очень

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

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

образом.

Под стилем программирования понимается внутренне согласованная со-

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

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

занных с этими программами.

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

вания,заключающиеся в совокупности соглашений о том,какие базовые кон-

цепции языков программирования и какие их сочетания считаются приемле-

мыми или неприемлемыми для данного стиля. Методология включает в себя

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

Методология реализуется через методики, которые состоят из следую-

щих компонент:

• Поощрение (или прямое предписание) использования некоторых базо-

вых концепций программирования.

• Запрещение (или ограничение) применения некоторых других базовых

концепций. Иногда запрещение либо ограничение может быть неяв-

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

го языка или его диалекта.

• Требования и рекомендации по оформлению и документированию про-

грамм.

• Совокупность инструментальных и организационных средств, поддер-

108

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

живающих все вышеперечисленные требования и рекомендации.

Предупреждение!

То, что в данном тексте называется “методикой программирования”,в ли-

тературе традиционно называется “методологией”, а то, что у нас обознача-

ется этим словом, называется “парадигмой программирования”.

Остановимся на методиках. Они направлены на поддержку деятельности

коллектива, работающего с программой, в том числе и ее автора (авторов).

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

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

мнению их разработчиков, приводит к хорошим результатам. Обычно пред-

полагается (иногда об этом говорится явно), что методика фиксирует опыт

практической разработки хороших и неудачных программ. Однако разные

методики чаще противоречат друг другу, чем согласуются, а потому появля-

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

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

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

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

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

следствием этого является их дискредитация. В результате эти действитель-

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

Важнейший аспект стиля и соответствующей ему методологии: запре-

щения и самоограничения. Необходимо твердо усвоить, что многие базо-

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

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

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

другу). Поэтому каждый стиль отгораживается от тех конструкций, которые

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

ма, выносите ее в под-, над- или сопрограмму)

. Большой бедой является то,

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

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

Заметим, что в программировании происходит систематическая ‘возгонка’ понятий. То,

что в других местах называется орудием, здесь называется методом; то,что называется мето-

дом или методикой, называется методологией; то, что называется методологией, возводится

в ранг парадигмы, и т. д. В данном пособии мы придерживаемся выражений, более адекват-

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

тикой.

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

3.1. СТИЛИ ПРОГРАММИРОВАНИЯ

109

великолепно работают.

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

работки. При этом требуется обобщение большого количества практическо-

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

влений. Из-за трудности задачи и во многих случаях из-за недостаточности

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

вообще не делался. Поэтому в данном курсе мы приводим только извест-

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

ме. Знать эти результаты особенно важно из-за того, что они дают не толь-

ко оптимистические заключения, но еще и серьезные предупреждения. Эти

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

принципиальной возможности что-то сделать (можно сравнить с прохожде-

нием программы через транслятор: то, что она успешно оттранслировалась,

почти ничего не говорит о ее правильности, а вот выданные при трансляции

предупреждения часто содержат ценнейшую информацию).

Так что в отношении стилей возникает та же ситуация, которая была с по-

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

конкретных и абстрактных аспектов: несущественные особенности конкрет-

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

роны, формальное внешнее сходство затушевывает серьезнейшие концепту-

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

Следует учесть, что разные стили ориентированы на разные модели вы-

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

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

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

серьезнейшие трудности при передаче опыта, при общении программистов,

при взаимодействии созданных ими систем.

Обратим внимание на другую сторону стиля. Составление программы —

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

естественном языке, чем это может показаться на первый взгляд. Конечно,

речь идет не о художественных текстах, а о тех, которые читают, чтобы по-

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

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

Поэтому рассмотрим читателей программы.

Самый очевидный читатель программы — это вычислитель, для которого

А непонимание и неучет читателя, соответственно, один из распространеннейших недо-

статков.

110

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

она составляется. С узко программистской точки зрения, ориентированной в

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

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

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

путь немедленно ведет в тупик. Так, ошибки при программировании (а это

правило; программист чувствует на себе, что атрибут человека — ошибка),

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

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

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

вынужден исправлять текст другого программиста. Следовательно, появля-

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

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

ций. Заметим, что обеспечить выполнение значительной части этих крите-

риев (но далеко не всех) можно, рассмотрев в качестве читателя абстрактно-

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

ния являются предметом деятельности программиста.Более того,чем глубже

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

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

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

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

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

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

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

текстов программ к восприятию человеком.Среди них в первую очередь нуж-

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

текста (использование пробелов,отступов, переносов между строками и др.).

Уже само по себе наличие комментариев говорит о том, что программа

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

ее автором). На практике же всегда приходится иметь дело и с другими чита-

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

в том, как она работает. Для поддержки этого процесса необходимы соглаше-

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

Низкий приоритет задачи не влечет, что ей всегда можно пренебречь, но практически все-

гда означает, что ею можно заняться в последнюю очередь. “Практически всегда”, в свою

очередь, понимается как: ‘всегда, если задача не заставляет нас явно заняться этим вопро-

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

торый чаще всего заставляет заняться вопросами эффективности — это ограничения.

3.1. СТИЛИ ПРОГРАММИРОВАНИЯ

111

прослеживается еще одна аналогия программирования с коммуникациями

на естественном языке: наличие стиля языка общения. Мы говорим о кан-

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

При этом всегда понимается, что следование определенному стилю накла-

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

выражения и т. д. С другой стороны, правомерно суждение о стиле языка че-

ловека: хороший стиль, выразительный стиль, бедный стиль и др. Подобные

характеристики свидетельствуют о соответствии способа изложения данно-

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

С точностью до мелочей понятие стиля может быть распространено на упо-

требление языков программирования. Так же, как и для естественных язы-

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

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

При анализе стилей программирования важно ответить на вопрос о том,

может ли быть стиль единым для разных языков. Мы не будем заострять

внимание на тех аспектах стиля, которые обусловлены конкретным синтак-

сисом — к синтаксису можно приспособиться и, тем самым, выработать тот

способ, которым реализуется стиль на данном языке. Но что касается модели

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

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

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

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

могут уживаться различные стили. Правомерно ли при программировании

сочетание стилей? Всегда ли оно будет приводить к эклектике

? Эти вопро-

сы — предмет ближайшего рассмотрения.

Наиболее распространенной (благодаря соответствующей архитектуре вы-

числительного оборудования и традициям программирования) является опе-

рационная модель фон Неймановского типа, базовая концепция которой —

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

§ 1.2). Следствием базовой концепции является то, что основной оператор

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

тельные операции хорошо согласуются с присваиванием, а какие противопо-

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

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

Эклектика — соединение по сути несовместимых вещей. Продукт эклектики часто на-

зывают химерой. Пример эклектики в одежде — фрак с джинсами или телогрейка с туфлями

на шпильках.

112

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

языка. Кроме них, есть еще круг вопросов, ответы на которые устанавливают

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

• Как структурировать априори однородную память?

• На какие логические и физические части должна разбиваться програм-

ма?

• Как преодолевать сложность процесса разработки программного обес-

печения?

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

программных решений и облегчать модификации программ?

Ответы на подобные вопросы формирут методологии и методики, реализу-

ющие стили программированния.

Из анализа опыта работы с фон Неймановской моделью вычислений вы-

являются свойства операционных программ, которые при надлежащей ин-

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

ния в нетрадиционных моделях вычислений. В частности, для этих моделей

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

глубине структурированности действий и данных, о связи структурирован-

ности с содержательным смыслом переработки данных, о степени развет-

вленности вычислений (аналоги рекурсии, условных конструкций и циклов

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

степень глобальности и локальности действий и данных. Поэтому возмож-

но проникновение стилей, сформировавшихся в рамках фон Неймановской

модели, в нетрадиционное программирование.

Более того, привязанность стиля к базису часто переоценивается. Напри-

мер, в книгах [37, 77] приведены методики, как структурно программиро-

вать для столь неструктурных языков, как старые ассемблеры,

FORTRAN

COBOL

Но некоторые из характеристик стилей, связанные с традиционной моде-

лью, являются специфичными для нее и не поддаются интерпретации вне ее

рамок. В первую очередь это касается операторов присваивания, в частно-

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

ная характеристика фон Неймановской модели — централизованное форми-

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

имосвязь этого порядка с порядком записи операторов в программе. Эта мо-

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

3.1. СТИЛИ ПРОГРАММИРОВАНИЯ

113

выполнении программы, задаются в повелительной форме. А можно ли стро-

ить программы, используя изъявительное наклонение? Как показывает опыт

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

достаточно красиво и эффективно!

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

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

являют подходящие для исполнения действия. Следовательно, нет нужды в

разбиении цели на приказы, последовательность которых приводит к реали-

зации цели, — система сама выстроит действия, нужные для достижения це-

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

ся соотношений между данными. В одной из первых монографий по языку

Рефал

[72] В. Ф. Турчин выдвигает любопытное положение: мерой развито-

сти естественного языка служит доля в нем изъявительного наклонения (чем

меньше приказов, тем язык богаче). Это утверждение выглядит еще более

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

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

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

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

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

мал, продуктивность их использования, разумеется, в своих сферах прило-

жения, уже тогда стала очевидной.

В теории разницу между изъявительным и повелительным наклонением

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

Если чрезмерно выделившуюся операционную модель вычислений фон

Неймана поставить на свое место в ряду других моделей, то становится яс-

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

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

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

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

Реализация идеи внедрения изъявительного наклонения в языки програм-

мирования возможна по следующим направлениям:

• Системы продукций. Соотношения записываются как правила вывода

предложения в некоторой грамматической или логической форме. Об-

рабатываемые данные сопоставляются с шаблонами, задаваемыми ча-

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

может быть применено. Соответствие данных шаблону трактуется как

разрешение применить данное правило. Применение правила состоит

114

ГЛАВА 3. ПРОГРАММИРОВАНИЕ С ПТИЧЬЕГО ПОЛЕТА

в замене выделенного при сопоставлении фрагмента данных на что-то

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

ный акт вычисления.

• Системы функций. Программа есть соотношение между функциями,

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

быть функциями. Таким образом, атомарный акт вычислений — это

подготовка аргументов для использующей функции. Готовность аргу-

ментов трактуется как разрешение вычисления функции.

• Коммутационные системы. Элемент системы — вершина графа, име-

ющая входные и выходные места. Входные места служат концами дуг, а

выходные, соответственно, их началами. Дуги — это каналы передачи

значений. Вершины, в свою очередь, могут иметь внутреннюю графо-

вую структуру, и так далее по рекурсии. Программа есть граф с дву-

мя выделенными вершинами, одна из которых не имеет входных мест

(генератор перерабатываемых данных), а вторая не имеет выходных

мест (получатель результата). Элементарное вычисление на графе мо-

жет активизироваться, когда ко всем входам вершины поступают зна-

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

действия (когда вершина атомарна), либо значения передаются по вну-

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

является появление значений на выходных местах (появление полного

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

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

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

ных в системе функций. В частности, если граф не имеет циклов, то

коммутационная система становится формой представления нерекур-

сивной системы функций.

Если граф коммутационной системы содержит циклы,то он может быть

проинтерпретирован как рекурсивная система фукнций. Такая систе-

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

граф, но не каждый бесконечный ациклический граф задает рекурсив-

ную систему функций. Но функции, связанные (возможно, косвенной и

взаимной) рекурсией — не единственная вычислительная модель ком-

мутационной системы.Имеются и другие модели,которые совмещают

параллелизм и системы состояний и переходов. Наиболее популярны

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