DRAKON.SU

Геннадий, так говорить совершенно... не знаю, как сказать мягче. Не обижайтесь, но не при Вашем качестве программирования "накатывать" на Дейкстру. Дейкстра - это практически единственное на сегодняшний день обоснование программирования. "Матанализ" для алгоритмов. И компания совершенно верная была. В рамках линейного текста - либо классическая "структурка", либо только goto. А в рамках того оборудования - только линейный текст, сами понимаете...

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

Вся аргументация имеется в книге.

Как сохраняются заблуждения описывается здесьссылка отсюда http://forum.oberoncore.ru/viewtopic.php?p=21993#p21993

Геннадий, я не один раз изучал книгу Паронджанова. Такой аргументации, как у Вас, там нет. Это Ваша интерпретация (резонанс ваших представлений с идеями Паронджанова).

Почитайте и Вы. Того же Дейкстру, "Дисциплину программирования". По части математики, которая в основе.

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

Книга Паронджанова содержит анализ сложившейся ситуации за 20 лет, после обоснования концепции "структурного программирования". И констатирует сложившийся разумный баланс теоретического обоснования с одной стороны и практики программирования с другой стороны.

Приведу раздел книги без изъятий (подчеркивание мое) :

==================================

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

Ортодоксальный метод Дейкстры, полностью запрещающий goto и заменители (см. с. 238, табл. 4, вариант 1), безусловно является строгим формальным методом. К сожалению, он полезен лишь как интересная теоретическая идея, которая, как показал всемирный опыт, в чистом виде оказалась непригодной для массового использования.

По мнению специалистов, “правила структурного программирования верны в 95%. Но остаются злополучные 5%” [20]. Чтобы поправить дело, решить проблему пяти процентов и создать метод, пригодный для широкой практики, пришлось пойти на компромисс и дать добро на использование заменителей и так называемое “ограниченное применение goto” (см. табл. 4, варианты 2—4). Благодаря этому проблема массовой практики программирования была решена. Но какой ценой? Ценой отказа от строгого формализма.

Это нетрудно показать. Например, авторы учебника языка СИ со¬ветуют осторожно и редко применять заменители break и continue, “поскольку слишком частое их использование ухудшает читаемость программы, увеличивает вероятность ошибок и затрудняет ее модификацию” [21]. Далее они пишут: избегайте использовать goto, ибо это “чрезвычайно плохое” средство, которое следует применять “как можно реже или не применять совсем” [21].

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

Следовательно, мы вправе сделать существенное замечание. Структурное кодирование, используемое в широкой практике программирования, не является формальным методом, так как к формальным правилам Дейкстры пришлось добавить неформальные правила, касающиеся goto и заменителей.

В шампур-методе аналогом goto и заменителей служат формальные операции “пересадка лианы” и “заземление лианы”, на использование которых не накладывается никаких неформальных ограничений.

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

===============================

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

Знать выводы Паронджанова полезно каждому программисту и сознательно, обосновано производить свой выбор средств реализации алгоритма.

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

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

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

Именно по этой причине (недозрелости)

В программировании управляющей логики (не вычислений, а поведения) часто встречаются ситуации, когда требуется несколько выходов из блока. Ситуаций-исходов, по которым идёт дальнейшее выполнение. (эти случаи видны сразу тем, что а) в случае IF начинается повторение одних и тех же действий в ELSE на разных уровнях б) в случае WHILE идёт повторение конъюнктов из его условия в виде отдельных IF... - "разруливание по ситуациям") Это - не break. Break как раз не позволяет выразить ничего, кроме досрочного прерывания и схлопывания всё на тот же один выход (на самом деле он выражает только одно - "я не умею грамотно вывести цикл, поэтому строю методом тыка, приклёпывая выходы").
Двумерное пространство чертежа позволяет превосходно выразить "разбегание" по ситуациям. Что и сделано в ДРАКОНе. Операции "пересадка лианы" и "заземление лианы" действительно являются формальными. Но могут быть выражены и по-другому, через аксиоматику на топологию графа.

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

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

Надеюсь, Вы поймёте, что я не ставлю своей целью обидеть Вас, не дай Бог, или что ещё...

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

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

Конечно, это Ваше право. Как может конкретный, строго обоснованный вопрос иметь фанатичный оттенок - я не знаю. Проблема в том, что у программистов, на его тему спорящих, обычно не хватает понимания на том уровне, на котором всё обосновано, - и тогда спор действительно выраждается во вкусовщину.

Советую внимательно и вдумчиво разобраться с вопросом. Если нет желания разбираться с мат. анализом программ, то хотя бы перечитать мои сообщения внимательно, чтобы понять, где Вы увлечённо перегибаете палку и срываетесь в неверные утверждения.

P.S. А вообще, я в "эмоциональном" смысле Вас не понимаю. Есть ДРАКОН. Никто не опровергает его принципы. Вы утверждаете, что ДРАКОН опровергает Дейкстру. Вам говорят, что нет, не опровергает, а даже наоборот. Что Вас не устраивает? То, что ДРАКОН перестаёт выполнять функцию "опровергания ненавистного Дейкстры", которую Вы ему самовольно приписали, так что ли?? Не понимаю.

Это можно упростить так:
"теория недостаточна легка для простых смертных"
vs
"программисткое быдло слишком тупо, что бы понимать очевидные вещи"

А это по сути "что в лоб, что по лбу"...

Как оказывается, не такие уж они и очевидные.

Похоже дискуссия вызвана недоразумением, невнимательным прочтением. У Тышова: "автор снимает те “табу”, запреты, заблуждения, которые сформировались ПОСЛЕ работ Э. Дейкстры...". Так что если это и "наезд", то не на Дейкстру. Это не новая ситуация, аналогичное было не раз, скажем с Марксом или даже с самим Христом.

Формальная полнота к.л. системы ещё не есть что-то дееспособное само по себе. Она может и самоцель для математика, но не для инженера. Одним "штрихом Шеффера", если не вру, можно заменить избыточный набор "и, или, либо, нет", машине оно и ничего, но каково с этого человеку?
ДРАКОН синтаксически строг, но графически избыточен. Для формальной реализации его синтаксиса достаточно графического набора {прямоугольник, отрезок, стрелка=указатель направления}. Но удобно ли оно инженеру?
ДРАКОН не есть "дисциплина программирования", предмет Дейкстры уже, специфичнее. ДРАКОН несводим к программированию, он "универсальный техноязык". И только потому что программирование - часть инженерии, то и ДРАКОН применим к программированию также.

Ну это уж если совсем упростить .

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

Тот кто уже увидел, что теория ЕСТЬ (но не может её сформулировать) не может доказать очевидность "ошибочности" тех, кто её ещё не увидел, и возможно НИКОГДА не увидит (просто потому что это им не нужно).

Универсальное руководство по убеждению инакомыслящих.
Для применения.

Забавно, только не понятно почему не на Драконе