В этом сообщении изложена Часть 4.
Примерно через десять дней последует Часть 5, в которой я продолжу отвечать на вопросы и критические замечания.
С глубоким уважением Владимир Паронджанов
Часть 4. Ответы Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования Дракон», , изложенные на первых трех страницах форума.Илья Ермаков Среда, 18 Июль, 2007 23:42 А самое интересное открытие сделал уже после прочтения, размышляя... Непонятно было, в какую конструкцию языка транслировать оператор верхнего уровня ДРАКОНа "ветка" (абстракция для подзадач, один вход, несколько выходов по адресам соседних веток, с возможностью образования "межветочных циклов). Это никак не вложенные процедуры, т.к. не происходит возврат в точку вызова... Неужели что-то GOTO-подобное? Но как-то не вяжется с общей идеологией языка, плюс смотрится удачным, выразительным средством. Потом допетрил: это детерминированный конечный автомат! В каждом состоянии выполняется некая ветка алгоритма, по окончании которой происходит переход в какое-либо другое состояние. И транслируется в цикл с вложенным CASE...
Это особенно интересно - прямая поддержка автоматного программирования.
Ответ ПаронджановаУважаемый Илья! В Вашем комментарии я выделил для себя фразу:
«Неужели что-то GOTO-подобное? Но как-то не вяжется с общей идеологией языка…». Именно эту фразу я попытаюсь прокомментировать.
Согласен, что оператор GOTO при неразумном употреблении может привести к неприятностям.
Но давайте сделаем «диковатое» предположение. Давайте вообразим, что у нас в руках волшебная палочка, которая гарантирует, что в данной программе GOTO ни при каких обстоятельствах не может вызвать ошибку. Проще говоря, волшебная палочка дает 100%-ю уверенность, что GOTO полностью безвреден. Кроме того, волшебная палочка делает оператор GOTO невидимым (для прикладного программиста). Как будто его (оператора GOTO) и вовсе нет.
При таком «диковатом» предположении становится совершенно безразлично, есть GOTO в программе, или он в ней отсутствует. Это значит, что в рамках моего предположения у нас нет никаких оснований испытывать «священный трепет» перед оператором GOTO.
Что же является волшебной палочкой, которая исключает ошибки при использовании GOTO? Такой палочкой служит дракон-редактор, который на 100% исключает ошибки подобного рода.
Предлагаемая мной «волшебная палочка» вовсе не является экзотическим исключением. В самом деле, после трансляции стандартных структурных конструкций (if—then—else, while—do, repeat—until и т.д. мы обнаружим в ассемблерной программе немало операторов перехода (о существовании которых многие программисты даже не догадываются). Прелесть в том, что эти операторы, будучи скрыты от программиста, не приносят никакого вреда.
Чтобы сделать эту мысль более убедительной, приведу заключительную часть главы 16 из моей книги (стр. 264—266)
Почему самолет не машет крыльями?
Говоря о будущем структурного программирования, необходимо осознать, что текстовое и визуальное программирование опирается на разные системы понятий, которые по-разному расчленяют действительность. Поэтому видеоструктурное программирование нельзя рассматривать как результат механического перевода устоявшихся понятий классического структурного программирования на новый язык.
Поясним сказанное. При визуальном структурном программировании программист работает только с чертежом программы, не обращаясь к ее тексту, подобно тому, как программист, работающий, скажем, на Паскале, не обращается к ассемблеру и машинному коду — они для него просто не существуют!
Это значит, что столь тщательно обоснованная Дейкстрой коллекция ключевых слов структурного кодирования (if, then, else, case, of, while, do, repeat, until, begin, end [2]) при переходе к визуальному программированию становится ненужной — для программиста она просто перестает существовать! В равной степени становятся лишними и отмирают и другие ключевые слова, используемые оппонентами Дейкстры в различных вариантах расширения структурного кодирования: goto, continue, break, exit и т. д.
Следует специально подчеркнуть: поскольку в визуальном варианте структурного программирования ключевое слово goto не используется, теряют смысл и все споры относительно законности или незаконности, опасности или безопасности его применения, а также обширная литература, посвященная обсуждению этого, некогда казавшегося столь актуальным вопроса.
Предвижу возражения: хотя названные ключевые слова действительно исчезают, однако выражаемые ими понятия сохраняют силу и для визуального программирования. Например, две видеопрограммы на рис. 27 можно построить с помощью понятий if-then-else и goto. Данное возражение нельзя принять, поскольку произошла подмена предмета обсуждения. С помощью указанных понятий можно построить не видеопрограммы, а текстовые программы, эквивалентные видеопрограммам на рис. 27.
Что касается собственно видеопрограмм, то они, будучи “выполнимой графикой”, строятся из “выполняемых” икон и “выполняемых” соединительных линий. Причем — подчеркнем еще раз — в процессе построения (которое реализуется с помощью ДРАКОН-редактора) пользователь не применяет понятия if-then-else и goto, ибо в этом нет никакой необходимости.
Нельзя путать задачу и систему понятий, на которую опирается метод ее решения. В обоих случаях — и при текстовом, и при визуальном структурном кодировании — ставится одна и та же задача: улучшить понимаемость программ и обеспечить более эффективный интеллектуальный контроль за передачами управления.
Однако система понятий коренным образом меняется: ту функцию, которую в текстовой программе выполняют ключевые слова, в видеопрограмме реализуют совершенно другие понятия: иконы, макроиконы, соединительные линии, шампур, главная вертикаль шампур-блока, лиана, атом, пересадка лианы, запрет пересечения линий и т. д.
Очевидно, что использование понятий, выражаемых ключевыми словами классического структурного программирования, не является самоцелью, а служит лишь для того, чтобы “делать наши программы разумными, понятными и разумно управляемыми” [22]. Указанные понятия решают эту задачу не во всех случаях, а только в рамках текстового программирования.
При переходе к визуальному программированию задача решается по-другому, с помощью другого набора понятий. Именно отказ от старого набора понятий и замена его на новый и позволяет добиться новой постановки задачи и более эффективного ее решения.
Поэтому высказываемое иногда критическое замечание: “недостаток шампур-метода в том, что он не удовлетворяет требованиям структурного программирования” является логически неправомерным. Нельзя упрекать самолет за то, что он не машет крыльями.
ВЫВОДЫ1. Визуальное структурное программирование (шампур-метод) и текстовое структурное программирование несоизмеримы (в куновском смысле слова), они опираются на разные системы понятий, которые по-разному расчленяют действительность.
2. Текстовое структурное программирование решило стоявшие перед ним исторические задачи, исчерпало свои эвристические возможности и, выполнив свою миссию, потеряло актуальность. В настоящее время точкой роста научного знания является визуальное структурное программирование.
3. При использовании шампур-метода набор ключевых слов классического структурного программирования становится ненужным. Благодаря этому создаются предпосылки, которые в будущем, возможно, позволят исключить ключевые слова и тем самым устранить путающий всех разнобой ключевых слов и структурных конструкций в разных языках программирования.
4. В отличие от текстового структурного программирования шампур-метод является полностью формальным.
5. По эргономическим показателям визуальное структурное программирование существенно превосходит свой текстовый аналог.
6. Широко распространенное мнение о несовместимости блок-схем и структурного программирования является мифом, нелепой ошибкой, основанной на невнимательном прочтении классической работы Э. Дейкстры “Заметки по структурному программированию”.
7. Дальнейшее использование неструктурных, неформальных и неэргономичных блок-схем во всех случаях следует признать нецелесообразным.
8. Существующая литература по блок-схемам, включая международные и национальные стандарты, на 99% устарела.
9. Современные стандарты на блок-схемы объективно содействуют снижению качества соответствующей интеллектуальной продукции. Указанные стандарты игнорируют три важнейших принципа: структуризации, формализации и эргономизации.
10. Актуальной задачей является разработка новой системы международных и национальных стандартов на блок-схемы, свободных от перечисленных недостатков. В основу проекта новых стандартов целесообразно положить изложенные в этой книге правила визуального структурного программирования. Дракон-схемы наследуют все или почти все достоинства блок-схем и устраняют их недостатки.
Конец цитаты из книги Паронджанова
AVC Пятница, 29 Февраль, 2008 15:10 Владимир Паронджанов писал: «Конструкция на рис. 26б не считается «структурной управляющей конструкцией». Поэтому она запрещена.
AVC возражает: А так ли это?
Насколько я понимаю, речь идет о рисунке справа на стр.116.
Вот я пишу
Код
if C or D or E or F or G or H then
B
else
A
end;
и получаю те же 2 ветки, что и на указанном рисунке.
Ответ ПаронджановаУважаемый AVC! Большое спасибо за Ваш вопрос. Он особенно дорог тем, что имеет предельно КОНКРЕТНЫЙ характер. Именно такие вопросы, как Ваш, позволяют наглядно продемонстрировать особенности Дракона.
Теперь по существу. Прежде всего, скажу, что, я, к сожалению, не могу с Вами согласиться. Причину изложу в виде 5 пунктов
Пункт 1. Сделаем обратное преобразование — преобразуем Ваш код в графическую форму. Ваша схема будет существенно отличаться от моего рисунка.
В самом деле, на рисунке справа на странице 116 имеются 6 икон «вопрос». А в Вашей схеме только одна икона «вопрос».
На рисунке справа на странице 116 имеются 6 развилок. А в Вашей схеме только одна развилка. Так что налицо важное графическое отличие.
Правда, с логической точки зрения обе схемы эквивалентны. Это, конечно, хорошо. Но этого мало.
Пункт 2. Схемы бывают не только хорошие (понятные), но и плохие (непонятные). При сравнении графических схем важна не только логика, НО И ЭРГОНОМИКА. А с эргономической точки зрения две рассматриваемые схемы различаются, как небо и земля. Ваша схема ТРУДНЕЕ для понимания. А схема на рисунке справа на странице 116 НАМНОГО ЛЕГЧЕ ДЛЯ ВОСПРИЯТИЯ (говорю не экспромтом, а на основании обширного многолетнего опыта).
Задача языка Дракон — выразить заданное смысловое содержание как можно проще. Чтобы было понятно даже ежу. Это значит: надо стремиться к тому, чтобы дракон-схемы были понятны не только программистам, но и непрограммирующим специалистам. Чтобы они могли проектировать алгоритмы по принципу «программирование без программистов».
Чтобы добиться этой цели, нельзя пренебрегать мелочами. Каждую, самую ничтожную мелочь надо изображать как можно проще, нагляднее, доходчивее.
Позволю себе метафору. Было бы желательно, чтобы программу (дракон-схему) смогли понять не только Вы, но и Ваша кошка. Предположим, Вы знаете математическую логику. А Ваша кошка не знает. В этом случае Ваша кошка совершенно точно не поймет Вашу схему (потому что она не знает, что такое дизъюнкция (or).
А в рисунке справа на странице 116 никаких значков дизъюнкции нет. Это значит, что данная схема проще для понимания. Подробное доказательство этого факта дано в главе 9 моей книги.
Пункт 3. Но это не все. Предлагаемое Вами логическое выражение
C or D or E or F or G or H, с логической точки зрения, является безукоризненно правильным.
Но,
если мы хотим облегчить работу непрограммирующего специалиста, читающего или пишущего алгоритм или программу, мы должны позаботиться о нем. И убрать с его дороги все коварные ловушки, рытвины, буераки и колдобины.
Одной из таких ловушек является логическое выражение в условном операторе.
Почему? Потому что условный оператор с логическим выражением для непрограммирующего специалиста представляет неоправданную трудность. Он увеличивает вероятность неправильного понимания и, как следствие, провоцирует появление ошибки.
Чтобы выявить суть возникающей здесь эргономической проблемы, я ввел понятие «главный вопрос условного оператора» (см. стр. 159—164 моей книги).
Главный вопрос — это тот самый вопрос, который мы пишем в иконе «вопрос» и на который надо ответить «да или «нет». Этот вопрос желательно записывать в явном виде — четко, ясно и недвусмысленно.
Если мы пишем в иконе вопрос логическое выражение, мы тем самым уничтожаем главный вопрос. Он исчезает, ускользает, улетучивается. И это плохо. (Подробнее см. главы 9 и 10 моей книги).
Пункт 4. Еще одна немаловажная деталь. Рисунок справа на странице 116 отличается высокой степенью абстракции. Поэтому он допускает двоякое толкование. До сих пор я придерживался того толкования, которое (на вполне законном основании) выбрал уважаемый AVC.
Сейчас я предложу другое, более удачное (с эргономической точки зрения) толкование.
Чтобы устранить двоякое толкование, надо на рисунке справа на странице 116 добавить слова «да» и «нет». Сделать это можно двумя способами.
1-й способ [«да» справа (6 раз), «нет» снизу (6 раз)]. Именно этот способ выбрал уважаемый AVC.
2-й способ [«да» снизу (6 раз), «нет» справа (6 раз)].
В последнем случае уважаемый AVC написал бы свой код по-другому:
Код
if C and D and E and F and G and H then
A
else
B
end;
Такой способ является более предпочтительным, так как схема описывается по стандартному правилу
слева направо (сначала А, потом В).
Пункт 5. Если строго соблюдать правило слева направо, то графические формулы для конъюнкции и дизъюнкции приобретают строго определенное, раз навсегда заданное графическое начертание (см., например, рис. 56 справа и рис. 59 справа.
Это значит, что бросив беглый взгляд на дракон-схему, мы сразу видим, где схема «И», а где схема «ИЛИ».
Конец Части 4. Конец ответов Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования Дракон», изложенные на первых трех страницах форума.Продолжение (Часть 5) последует примерно через 10 дней.