DRAKON.SU

Наконец нашлось время, попробовал. Никаких трудностей и особенностей "управляющих алгоритмов" не обнаружил. Переписал только верхний рисунок, т.к. он самый сложный.
Несколько замечаний.
1. Ключевые слова набраны строчными буквами и выделены подчеркиванием. Потому, что именно так это рождается на бумаге. Для тех, кому-то режут глаз строчные буквы и это мешает восприятию, добавил вариант с прописными буквами.
2. В реальности я, возможно, попытался бы уменьшить вложенность конструкций. Но в данном случае старался сделать, по возможности ближе к оригиналу.
3. В отличие от Дракона, текст готов к ручной трансляции на целевой язык. Не функциональный, конечно.
4. В псевдокоде, если есть цикл, так это цикл, у него есть границы, видна охрана, можно сформулировать инвариант и постусловие, наконец, его можно выделить как отдельную процедуру. В отличие от идиотского нагромождения гробиков со стрелками и фирменного изобретения "цикл со многими выходами"
5. Самое важное. Я никогда не использовал Дракон, что неудивительно. И только сейчас почувствовал, насколько т. н. "наглядный рисунок" СКРЫВАЕТ границы циклов.
Значит, говорите, "В основании Дракона очень серьезная математика" и "Парджанов улубил Дейкстру"?
Ну, ну.

Резюме по Дракону. Это поделка от недоучки в программировании и для недоучек. Причем она эффективно закрепляет их на этом уровне.

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

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

В управлении цель - обеспечить правильную последовательность событий во времени. Постусловие может быть единственное - "последовательность событий была правильной". Сравните с вычислительной задачей, где последовательность, путём которой достигнуто постусловие - вычислен результат - никого не интересует.

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

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

Разве только?
Можно сказать: обеспечить корректное состояние в каждый момент времени.
Корректность -- тот же инвариант.

Совершенно точно.
И инвариант - обязательно, куда ж без них!

Ключевая фраза: "Наконец нашлось время"

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

И это оно еще помещается на одной странице (думаю, что в реальных кодах это 2-3 страницы)...
Нет слов

(Кстати, Пётр, Вы знакомы с новосибирскими работами по теории схем программ?)

Вообще, я уже сказал и показал, все что хотел. Спорить до бесконечности я не собираюсь. Нравится Вам Дракон – флаг в руки.
По замечаниям:
1. Дублирование – это плата за структурность. Не готовы ее платить, да на здоровье, платите за использование GOTO. Для цикла Дейкстры, помнится, Вы готовы были ее платить.
2. Рассуждения о последовательность событий во времени выглядят как передергивание, в исходной картинке (ТЗ) ее не больше, чем в переписанном тексте. Нет в ней и формализма Хоара, почему я должен "его взять"?
"Я должен потратить уйму времени, чтобы понять, как Ваш алгоритм будет вести себя во времени" – этой фразы я не понял, то же самое я могу сказать о драконовских схемах. Если есть ошибки или неточности, то их и приводите.
3. В регулярных выражениях циклы правильные, на то они и "регулярные".
4. По поводу написать-записать и последующего многократного чтения. Да, такая проблема есть. В принципе, чем дальше язык программирования от псевдокода, тем она острее. Правда, для ассемблера, она решается на 100%. Предложения псевдокода записываются как комментарии к командам, а специальная программы выделяет их из текста и получает текст на псевдокоде аналогичный приведенному. Это не фантазии, я использовал такую технологию, когда работал на ассемблере. Она прекрасно себя зарекомендовала во всех случаях, от ЛИСП-машины до BIOSа.
В более высокоуровневых языках такой подход не оправдан.

Нет, если приведете ссылки, буду благодарен.

А тогда в чем разница.

Если я правильно понял, Вы что-то где-то нарисовали. Так выкладывайте здесь, посмотрим.

Так инвариант - это рассуждение в терминах "законов сохранения".

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

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

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

(Нет, я, конечно, понимаю, что всё это можно трактовать как постусловие - типа, "были нужные события". Но это уже схоластика).

Ряд работ Ершова.
В частности, книга "Введение в теоретическое программирование".
http://www.ershov.ras.ru/archive/eainde ... &did=37478

Книга Котова, Сабельфельда "Теория схем программ".

Другие публикации ИСИ СО РАН.



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

Цель любого формализма - сделать возможным уверенное рассуждение об интересующих нас свойствах интересующего нас объекта. Только с такой точки зрения можно доказывать "правильность-неправильность, научность-ненаучность..". Обратите внимание, сколько оговорок: "уверенное рассуждение", "интересующих нас.." (т.е. если по Вашему замечательному и сто раз правильному тексту я не могу быстро отвечать на интересующие меня вопросы, то ни о какой "формальной правильности" рассуждать смысла нет. А вопрос меня интересует, например, элементарный: ставлю палец в некоторую точку алгоритма и спрашиваю - а какой последовательности сообщений я могу ожидать? и т.п.)

Касательно регулярных выражений - регулярные языки эквивалентны языкам, описываемым конечными автоматами. Конечный автомат может включать произвольные циклы. Нет, в конечном счёте его можно разложить через ИЛИ в набор линейно-цикличных участков, с дублированием. Но стоит или нет - зависит от конкретного случая. Так же, как алгоритм можно развернуть до полной древесной развёртки (т.е. после развилки выполнение не сходится в одной точке, вместо этого общее окончание дублируется). Форм представления может быть много. Нужно выбирать ту, которая выявляет нужные нам свойства.

Почему же схоластика. "Не умножай сущности..."

здесь

Вы противоречите себе.
Если они сделали, то уже нельзя назвать их недоучками.
Заинтересовавшихся Драконом Вы так же называете недоучками, но ведь и Вы же давно неравнодушны к данной теме. Из 60 Ваших сообщений - 23 на форуме в ветке ДРАКОН.
Вы что то хотите противопоставить ДРАКОНУ, он Вам мешает?

Почему у Вас такой мрачный взгляд на реальность? Лучше стать позитивнее.

Это тема не этого раздела форума, а другого. Заходите, на любой Ваш вопрос - любой наш ответ.
Здесь я хотел обратить внимание на соотношение 1/15, а не на 5/15. Причем, корректное сравнение будет при заведомом понимании синтаксиса, в т.ч. и визуального. А оно у нас несколько отлично от ДРАКОНовского.
Образно говоря, некий граф алгоритма мы и ДРАКОН проектируем на разные плоскости. Возможно, и на взаимо-перпендикулярные...

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


Поделюсь опытом... не таким и маленьким, как отмечал выше
В 8 случаях из 10 - это психология
Человек несколько лет изучал ЯВУ, набивал шишки на ловушках в C++, заморачивался с классовой иерархией визуальных библиотек, и т.п..
А тут - приходит лох, который только вчера узнал что такое цикл FOR, и через 10 минут запускает программу с не меньшей функциональностью
Обыдно, да

Скромно замечу, что два последних поста являются офтопиком в данной теме.
По-моему место для того, чтобы выложить альтернативные решения вполне подходящее, т.к. ТЗ в виде схем на Драконе одно и то же. Ну, если не хотите - дайте тогда URL.

Гробик - это вполне нейтральный термин для обозначения блока с условием. Тоже самое, что и ромбик, только удобнее.

Я бы так не сказал... Полагаю, не стоит употреблять такой, с позволения сказать, сленг...

Ваш вариант?

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

Всё, достаточно, а то уже оффтопик начался полный...