DRAKON.SU

Уважаемые коллеги!

Предлагаю вашему вниманию
отрывок из книги

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

Прошу вас высказать критические замечания и указать на недостатки
этого текста.

Глава 23
ВИЗУАЛЬНОЕ СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ

Наше мышление основано в первую очередь на зрительном восприятии.
Вадим Глезер [1]

ПОСТАНОВКА ПРОБЛЕМЫ

Введем термин «визуальное структурное программирование».
Определим его как набор правил, совпадающий с визуальным
синтаксисом языка ДРАКОН. В концентрированном виде эти правила
изложены в главе 22.

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

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

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

• Для визуального программирования подобное утверждение
неправомерно. Можно, конечно, тупо перенести правила текстового
структурного программирования на визуальный случай.
Но это не будет хорошим решением.

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

• Принципы структуризации, положенные в основу визуального
синтаксиса языка ДРАКОН, являются искомым решением.

В данной главе сделана попытка обосновать заявленные выводы.
В качестве исходной точки для нашего анализа возьмем работы
Эдсгера Дейкстры.

Продолжение следует

ГЕНИЙ ПРОГРАММИРОВАНИЯ

Эдсгер Вибе Дейкстра (1930—2002) — выдающийся нидерландский
учёный, идеи которого оказали огромное влияние на развитие
программирования.

В 1970-е годы вместе с Чарлзом Хоаром, Никлаусом Виртом и др.
он разработал основные положения структурного программирования,
ставшего классикой методологии разработки программ.

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

Для решения этой задачи Дейкстра ввел строжайшую «дисциплину
программирования» [3]. Эта дисциплина, то есть совокупность жестких
правил, призвана обеспечить интеллектуальный контроль за разработкой
программ и минимизировать программные ошибки.

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

Работы Дейкстры по структурному программированию послужили
исходной идеей для разработки языка ДРАКОН. Предлагаемое нами
визуальное структурное программирование — это непосредственное
развитие идей Дейкстры.

Почему возникла необходимость в таком развитии, то есть
в существенной доработке идей нидерландского ученого?
Можно указать три причины.

• Дисциплина программирования Дейкстры является неоправданно
жесткой. Она вводит излишние запреты и лишает программиста
свободы. Образно говоря, она заковывает программиста
в кандалы и затрудняет его работу.

• Дейкстра недооценил потенциальные возможности блок-схем
(flow-charts). И не сумел дать блок-схемам строгое математическое
обоснование, пригодное для трансляции блок-схем в объектные коды.

• Дейкстра не был знаком с когнитивной эргономикой и не смог
превратить блок-схемы одновременно и в эргономичный,
и в математический объект. Впрочем, он и не ставил перед собой
такой задачи.

Продолжение следует

НЕДОЧЕТЫ В РАБОТАХ ДЕЙКСТРЫ

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

В чем суть? Как известно, Дейкстра ввел три управляющие
конструк ции: сочленение (последовательность), выбор (развилка),
повторение (цикл). Внимательно прочитаем его рассуждения:



Что же мы узнали? Дейкстра выделяет три понятия: сочленение,
выбор и повторение. Он называет их ОПЕРАТОРАМИ управления.
С точки зрения математики это место не совсем корректно.

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

Конечно, само сочленение есть: оно состоит в том, что команды
пишутся подряд. Но ОПЕРАТОРА сочленения нет.
Выходит, что некоторые операции из выделенной Дейкстрой тройки
понятий имеют операторы и ключевые слова, а другие нет.
Это некрасиво (а если отбросит деликатность — не строго).

Следующий вопрос. А где оператор вложения?
Ведь само вложение есть (например, «цикл в цикле»).
А оператора вложения нет. Налицо логическая неувязка.

Продолжение следует

КАК ПОПРАВИТЬ ДЕЛО

Этот недостаток можно легко устранить, если изменить общий взгляд на процедурное программирование. Каким образом?

Для этого необходимо:

• заменить линейный текст программы на графический;

• во главу угла поставить не три текстовые управляющие структуры
Дейкстры, а операцию — вложение. Причем операцию вложения
следует рассматривать сквозь призму математической логики.
Как логический вывод.

В языке ДРАКОН именно так и сделано. Подробные объяснения
читатель найдет в главе 24. Но уже сейчас можно дать
предварительные пояснения.

Уже говорилось, что в ДРАКОНе важную роль играет операция
«ввод атома». Добавим сюда же «ввод ветки».
Эти операции есть не что иное, как вложения.

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

• В варианте Дейкстры команды пишутся подряд (при этом форма
написания программы «не подталкивает» программиста к тому,
чтобы заглянуть в конец программы).

• В варианте ДРАКОНа в заготовке-примитив и в заготовке-силуэт
программист сразу видит не только начало, но и конец.
Почти все визуальные операторы вставляются в дракон-программу
с помощью операций «ввод атома» и «ввод ветки». То есть с помощью
вложения.
Причем указанные операторы вставляются между началом и явно
указанным концом программы. Таким образом, программа строится
с помощью цепочки вложений. Атомы вставляются между началом
и концом заготовки. Преимущество в том, что цепочка вложений
помогает программисту вырабатывать ЦЕЛОСТНЫЙ, ОБЗОРНЫЙ
взгляд на программу, включая ее начало и конец.

В визуальном структурном программировании предлагается
отказаться от трех текстовых управляющих структур
(последовательность, развилка, цикл) и использовать визуальную
управляющую конструкцию — вложение. Кроме того, предлагаются
операции с лианами.

Продолжение следует

ПРЫЖОК ИЗ ЦАРСТВА НЕОБХОДИМОСТИ
В ЦАРСТВО СВОБОДЫ

Рассмотрим следующий недостаток. Дейкстрианская революция
состоит в том, что Дейкстра ввел строгую дисциплину в анархическом
царстве процедурного программирования. Но любая дисциплина —
это ограничение свободы. Недостаток в том, что Дейкстра ввел
неоправданно жесткие ограничения. Фактически Дейкстра добился
успеха за счет того, что ввел интеллектуальное рабство и заковал
программистов в кандалы.

Первые голоса протеста прозвучали в самом начале его мощной
атаки против засилья анархистов. Оппоненты доказывали,
что знаменитый лозунг Дейкстры «оператор goto вреден»
(GOTO statement considered harmful [4]) в ряде случаев не верен.
Со временем им удалось заметно облегчить тюремный режим и
сделать кандалы более легкими. Они, использовали приемы,
которые я называю «заменителями goto» (см. объяснения чуть ниже).

Подчеркнем главную мысль. Мы предлагаем отказаться
от линейного текста программы и превратить ее (программу)
в графическую дракон-схему.

Если сохранить линейный текст программы, то прогресс невозможен.
Тюрьма неизбежно будет тюрьмою. И железными решетками
на ее окнах по-прежнему останутся так называемые «текстовые
структурные управляющие конструкции».

Когда-то они сыграли позитивную роль и помогли победить
анархистов (как иногда говорят, превратить программирование
из шаманства в науку).

Сегодня тюрьма имени Эдсгера Дейкстры тормозит повышение
производительности труда программистов. Почему? Потому что
Дейкстра построил удивительно прочную тюрьму, в которой
почти все запрещено. Куда ни повернись — все нельзя!

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

Эту задачу и решает язык ДРАКОН. Следуя по мудрому пути,
начертанному великим Дейкстрой, визуальный язык ДРАКОН,
тем не менее, устраняет кандалы и разрушает тюрьму, построенную
Дейкстрой. И позволяет совершить прыжок из царства необходимости
в царство свободы.

Каким образом? Благодаря замене текстового структурного
программирования на визуальное структурное программирование.
Последнее, разумеется, также является дисциплиной.
Но в ней большинство запретов снимается. То, что раньше было
нельзя, теперь можно.

Многие запреты Дейкстры «перегибают палку»; они противоречат
здравому смыслу и затрудняют понимание алгоритмов и программ.
Пример приведен на рис. 46.

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


Конструкция на рис. 46 не считается «структурной управляющей
конструкцией». Поэтому (согласно Дейкстре) она запрещена.
Что отсюда следует?

Наш ответ таков: пусть текстовые управляющие конструкции
отправляются на заслуженную пенсию. Потому что во многих случаях
(хотя и не всегда) они искажают нормальный ход человеческой мысли.

Недопустимо запрещать правильный процесс мышления. Его надо
разрешить. И ДРАКОН разрешает.

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

Продолжение следует

НОВАЯ ФИЛОСОФИЯ ПРОЦЕДУРНОГО ПРОГРАММИРОВАНИЯ

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

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

ДРАКОН — это не просто новый язык (новое семейство языков).
Это новый взгляд на процедурное программирование.
Если угодно — новое мировоззрение.

Уважаемые коллеги!

Прошу высказывать критические замечания.

Первое, что приходит в голову - Дейкстра также реализовал принцип вложения в цикле своего имени. Именно поэтому возможно визуализировать эту конструкцию, как показано, скажем, в этом пункте для определения соответствующего диалекта техноязыка. И именно логика привлекается при структурировании циклического (или сводимого к циклу) алгоритма по Дейкстре, что показано, напр., на этой странице в п. Структурирование "промышленного" цикла". Если исходить из правоты сторонников такого структурирования (см. Илью в этом сообщении) - то исчезает необходимость в заменителях goto, вводимых визуально пересадками лиан, а текстово - break и continue. О возможном соответствии между ЦД и силуэтом уже сказал - в этом сообщении
Посему вижу не конфликт, а общую почву для метода Дейкстры и шампур-метода (в редакции, учитывающей ограничения Дейкстры).

Уважаемый Владимир Даниелович!

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

Вот здесь общая суть текста выражена ясно:



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

Во-первых, дело в том, что "Дисциплина программирования" Дейкстры - это отнюдь не ограничения структурного программирования. Структурное программирование было "выращено" чуть раньше, и как Вы заметили в тексте, усилиями ряда деятелей-современников. "Дисциплина программирования" - это способ рассуждать о свойствах программ, выводить программы из логических рассуждений так, чтобы их правильность была строго доказана. "Дисциплина программирования" Дейкстры вообще не имеет прямого отношения к вопросам, которые затрагиваются в тематике Дракона и структурного программирования. Факт относительно Дейкстры лишь в том, что программы должны быть некоторым образом упорядочены, а затем над ними можно строго рассуждать. Над Дракон-схемой можно точно также рассуждать в соответствии с "Дисциплиной программирования" Дейкстры, как и над классической структурной программой.

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

Вот этот абзац:

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

И вот этот абзац тоже:


Опять же, ДРАКОН снимает противоречия, окончательно "убивая" попытки реабилитировать GOTO. Теперь и ряд случаев, на которые классического структурного программирования "не хватало", прекрасно выражаются конструкциями двумерного структурного программирования ДРАКОНа.

А доказательства оппонентнов Дейкстры были связаны с более широким неприятием дисциплины. GOTO против процедур, GOTO против нормальных циклов, вообще "вермишель" против структуры - в этих позициях некоторое число задач, в которых реально что-то было "не так" у структурного программирования, просто терялось.

Таким образом, и этот абзац уже оказывается ни к чему:


Поясняю, почему: он даёт впечатление, что было сначала чрезмерно сильное и неверное ограничение, а вот теперь "вернулись немного назад". Но ведь это не так! Двумерное структурное идёт вперёд, а не назад. Оно решает некоторые проблемы, вводит некоторые структуры, которые раньше ещё не были придуманы. Ограничения, которые существовали, не были неверными, они просто были для текста единственно возможными. Появилась возможность их снять - и она была Вами реализована. Вот и всё. Ровный, уверенный, логичный шаг вперёд, без каких-то "откатов" и "возвратов". Разве нет?

==========

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

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

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

Кроме того, там, где автоматы. Синтаксические задачи - иногда рисую автомат, иногда просится ДРАКОН-схема.

Илья Евгеньевич!

Большое спасибо за замечания. Буду думать.

Уважаемый Владислав!

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

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

Уважаемый Владимир Даниелович!

На мой взгляд, Вы предлагаете читателю очень тонкую игру на противоречиях, которые на сегодняшний день отсутствуют. По Дейкстре основной ответ уже есть выше, у меня лишь небольшое дополнение:

1. Стиль программирования с помощью "вложений" описан также в материалах по языку Эль-76(напр.: Сафонов В.О. "Языки и методы программирования в системе ЭЛЬБРУС", 1989г.). "Программирование на языке выражений" реализовано с помощью замкнутых, условных, выбирающих и структурных выражений, объединяемых понятием "закрытое выражение". Более того, стиль многих практикующих программистов основан на "вложениях" - сразу после написания управляющего оператора, целиком набирается ограничивающая конструкция begin - end или { }. Многие IDE могут автоматически подставить ограничивающие конструкции. Далее программист набирает текст уже внутри конструкции, формируя ту самую цепочку "вложений". И это не воспринимается, как нечто необычное.

2.по поводу оператора сочленения(чтобы читателю не потерять связь с реальностью) (отсюда):И, кстати, вложенные выражения соединяет этот же оператор.

3.В обоснование Дракона всё-таки выгоднее акцентировать внимание на том, что соблюдение простых графических правил приводит к построению правильной структурированной императивной программы (по всем действующим на сегодня канонам, и по Дейкстре - в том числе). При этом, усвоение даже такого краткого набора: может вызвать дальнейший интерес. (выборка маленькая - всего 10 чел., из них двое детей (6 и 9кл.), три программиста, остальные - можно сказать "предметники").

Я бы назвал это резче и грубее: софистику.

У меня нет окончательного вердикта насчет идей в Драконе, но софистика в качестве обоснования -- это нехорошо.

Дипломатично лукавите. Вы прекрасно разобрались с Драконом, чтобы вынести вердикт: "с этим не надо разбираться". Никакого "улучшения работы ума" на горизонте не просматривается.
А после этого делаются заявления, я, типа, не специалист по Дракону, у меня нет окончательного вердикта и т.п.

Выскажу собственное мнение.
Со следующими "постулатами" я не согласен:

Ограничение на типы структур (последовательность, ветвление, цикл) Дейкстра вводит не случайно. Если придерживаться этих структур, то построение программы и проверка правильности программы облегчается.
То есть текстовые структуры каким-то образом преобразуются в мысли в нашей голове и там обрабатываются.
Не понятно, почему при переходе от текстового представления к визуальному должно что-то кардинально меняться. Да становиться немного легче проследить структуру программы, но из-за этого мы не должны вводить новых структур.
Например, мы привыкли, что в математике есть следующие основные операции +, -, *, /.
Допустим, я говорю, давайте записывать математические формулы визуально (например, в виде дерева). Все согласны, да это нагляднее, да это лучше.
Теперь я говорю, раз стало проще, почему бы еще не ввести новые математические операции, такие как -*- , который означает x -*- y = (x - y) * (y - x), и добавим операцию // , который означает x // y = (x/y)/y.
Сами понимаете, что не нужно вводить новых математических операций.
То же самое с Драконом, вот есть структурное программирование, считаю, что Дракон должен позволять выражать программы записанные в структурном виде, и наоборот программа записанная в виде Дракон-схемы должна быть способна записываться в структурном текстовом виде.

Это две разные вещи: не имею окончательного вердикта и не вижу причин сейчас с ним разбираться.
Илья Евгеньевич показывал мне какую-то математику, и там было нечто похожее на содержательность.
Если это будет дожато и предъявлено -- обязательно посмотрю.

В свое время, когда работал в НПО "Импульс" (комплексником) пытался использовать подобные вещи, только не Дракон, а SDL. По моему, имеет смысл только если это плотно поддерживается на уровне предприятия (как у Пилюгина). В противном случае - лишняя головная боль. В тоже время к попыткам создать нечто универсальное отношусь с уважением.

Тут дело даже не в деликатности, а в том, что очень общее соображение стоит изменить. Об этом подробно сказал Илья, а если кратко - то о Дейкстре, стоит говорить не как об авторе концепции текстового программирования (алгоритмизации, точнее), а как об авторе концепции доказательства правильности алгоритмов, их вывода "уже правильными" в смысле логико-математической постановки задачи. И эта концепция стоит над классификацией формализуемых знаний (в Вашей ли редакции, в моём ли расширении/уточнении, проведённом в этом пункте - здесь не имеет значения) - потому, что она ГРАФИТна , т.е. исходит не только из топологии маршрутов, но прежде всего - из смысла условий выбора этих маршрутов (который, в свою очередь, неотделим от используемых величин алгоритма).
Посему эту концепцию с равным успехом можно приложить и к текстовому и к ГРАФИТному представлению деятельности - надо только формализовать постановку задачи до математического метауровня (стадии в смысле определения формализации Фридландом, уточнённого на этой странице) - что и показано как в "Алгоритмах и структурах данных для Оберона", так и таких в примерах, как "Структурирование "промышленного" цикла". А у Карпова в книге по Model Checking показано, что если представить логику системы процессов на языке типа Promela - то их можно верифицировать в автоматических системах, для которых такой язык является входным - при этом по смыслу неважно, программно-аппаратная реализация подразумевается или оргтехническая (т.е. трудовой процесс в исходном смысле, то что сейчас называют "бизнес-процесс"). Отсюда и потребность заняться как циклом Дейкстры, так и согласованием механизмов формализации взаимодействия совместно протекающих процессов в разных языках (напр. в Активном Обероне и в Promela).
Сказанное, кстати, не значит, что любой сочинитель (и я в том числе) , получив в своё распоряжение подобные языковые возможности, так сразу и сможет доказательно строить эти системы процессов - но я осознаю необходимость этого и необходимость этому учить когнитивно-эргономично - т.е. не ограничиваясь традиционной математической нотацией, а привлекая визуальные методы. Вы к этому призывали в /Паронджанов, 2001, Гл.19/ - приходит время это воплощать в жизнь - именно математика вывода алгоритмов м.б. удачной "стартовой площадкой". Это, кстати, будет и "лучшим памятником Дейкстре"
Посему под новым углом зрения стоит рассматривать приведённые части содержания книги... и возможно, не только приведённые... и к "детско-юношеской" литературе это относится (о чём уже говорил в этом сообщении).

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

P.P.S. Совместно протекающие взаимодействующие процессы понимаю в смысле Гл.4 из работы Корнеева (выдержка вложена в это сообщение).
Главу из Карпова с примерами верификации вложил в это сообщение.
Только не стоит обращаться ко мне с вопросами по математическому смыслу и/или по его визуализации - то, что я прочитал эту работу, не значит, что я понимаю на математическом уровне весь её смысл - большинство соображений здесь у меня качественные, и их я уже высказывал - прежде всегов этом подпункте. Впрочем, как наглядно представить смысл "неподвижной точки оператора", кажется, могу предложить - если взять клеточно-автоматные модели типа известной игры "Жизнь" Конвея, то там возникают ситуации, когда после очередного хода конструкция из фишек только меняет своё положение на поле либо вообще остаётся неизменной - вот это и получается неподвижная (с точностью до координат или в полном смысле) точка для оператора, задающего правила совершения хода...
Кстати, в п. 8.1 использован ещё один язык визуализации систем процессов...

Вот-вот, "оператор сочленения" это тот самый "естественный" тип перехода, возможный наряду с безусловным... а условный практически реализуется выбором опять-таки либо естественного, либо безусловного, что показал Свердлов, например:

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