DRAKON.SU

Саму простую вещь: в цикле шагают две вещи в параллель: i и ридер. И "умереть" они должны вместе.
Я лично отношу подобные хитрости к разряду "преждевременная оптимизация".

Странно. По мне так это аналог копирования подстроки из одной строки в другую, поэтому индексы (i и ридер) по строкам и шагают вместе.

А. Действительно. Только почему тогда цикл такой ... неясный?

Уважаемый Александр Ильин!

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

К сожалению, в процессе работы Вы допустили ошибку. Причем серьезную. Я (про себя) называю эту ошибку нарушением «Золотого правила».


Раздел 1. Что лучше: примитив или силуэт?

Ответ на этот вопрос дает «Золотое правило», которое звучит так (см. мою книгу «Как улучшить…», стр. 91:

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

Дальше в книге даются дополнительные пояснения.

Например, алгоритм на рис. 6б выглядит громоздким и неоправданно сложным для восприятия. Это вызвано тем, что он содержит 19 икон, однако изображен в виде примитива. Криминал в том, что схема на рис. 6б не позволяет читателю мгновенно (за несколько секунд) распознать визуально-смысловую структуру алгоритма. В самом деле, из скольких частей состоит решаемая проблема? Глядя на рис. 6б, ответить на этот вопрос довольно трудно, а быстро ответить — невозможно.

Положение в корне меняется, когда мы смотрим на рис. 6а, где тот же самый алгоритм изображен в виде силуэта. Тут, как говорится, и ежу ясно: алгоритм состоит из четырех частей: “поиск автобуса”, “ожидание посадки”, “посадка в автобус”, “поездка”. Однако это не все: не менее важно и то обстоятельство, что запутанность зрительного рисунка исчезла и схема приобрела новое эстетическое (эргономическое) качество: элегантность, ясность и прозрачность.

Таким образом, в сложных случаях силуэт позволяет существенно уменьшить интеллектуальные усилия, затрачиваемые на понимание алгоритма.
В силуэте крупные структурные части программы (ветки) четко выделены, они пространственно разнесены в поле чертежа, образуя вместе с тем легко узнаваемый, стабильный, предсказуемый и целостный зрительный образ.
А в примитиве структурные части не выделены и перемешаны (“всё в одной куче”), что затрудняет чтение и анализ сложных алгоритмов.
Однако для простых случаев (менее 5...15 икон) примитив, как правило, оказывается более предпочтительным.
Конец цитаты.

Раздел 2. Программа Александра Ильина. Как ее лучше изобразить на Драконе: в виде примитива или в виде силуэта?

Уважаемый Александр Ильин!
В Вашей программе (см. сообщение viewtopic.php?p=14681#p14681 )

используются 68 икон. Это намного больше, чем 5…15.
Отсюда (согласно золотому правилу) следует, что в Вашем случае нужно использовать силуэт. А использование примитива недопустимо.
Однако Вы, к сожалению, выбрали примитивы.
Это вызвало негативную реакцию у участников обсуждения.







Мысль Ермакова я бы выразил несколько иначе. Дело не в том, что пример неудачный, а в том, что нарушено «золотое правило».

Учитывая «золотое правило», хочу добавить, что правильным подходом является вариант Ильи Ермакова, в котором строго соблюдается «золотое правило».
Оценивая схему Ермакова,



Для строгости следует добавить, что в схеме Ермакова тоже есть недостатки, но они незначительны. Сегодня я о них говорить не буду, чтобы не «размазывать» картину.

Раздел 3. О пользе ошибок.

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

Уважаемый Александр Ильин!

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

Обстоятельно поблагодарили : )

Уважаемый Александр Ильин!

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

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

Это было предисловие. А теперь самое главное. Ваше исследование в рамках данного форума является пионерским. Оно было тщательным и всесторонним. Именно Ваше исследование позволило другим участникам форума перейти от ТЕОРЕТИЧЕСКОГО обсуждения Дракона к ПРАКТИЧЕСКОМУ анализу.
Это грандиозный шаг вперед.

По-моему мнению, РЕЗУЛЬТАТОМ СТОЛЬ ВАЖНОГО ИССЛЕДОВАНИЯ ДОЛЖНА БЫТЬ РАЗВЕРНУТАЯ ОЦЕНКА ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ САМИМ АВТОРОМ ЭКСПЕРИМЕНТА, ТО ЕСТЬ АЛЕКСАНДРОМ ИЛЬИНЫМ. ЗА ЭТИМ ДОЛЖНА ПОСЛЕДОВАТЬ ДИСКУССИЯ.

К сожалению, сейчас это не так. По состоянию на 27 апреля 2008 обсуждение столь важного эксперимента оказалось оборванным на полуслове. А заключительное слово автора (Александра Ильина) отсутствует.

Уважаемый Александр Ильин!

Я был бы очень рад, если бы Вы сочли возможным изложить свою позицию по затронутым мною вопросам.

С глубоким уважением и благодарностью за Ваш бесценный вклад
Владимир Паронджанов

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

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

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

С другой стороны, я ведь разбил алгоритм на независимые части-процедуры, которые и оформил в виде примитивов. Ни в одном из примитивов не встречается более 13 блоков, не считая "заголовока", "параметров" и "конца" (а если последовательные действия объединить в "полки", то будет не более 9 блоков алгоритма на процедуру), так что за верхний лимит "15" я формально не вышел.

Ничего не имею против. Я ведь даже книгу-то не нашёл времени толком прочитать, не то что все правила соблюдать. Фактически, только благодаря редактору я и познакомился в какой-то мере с языком, за что ещё раз выражаю Геннадию Тышову свою признательность.

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

Схема выполнена в редакторе MS Visio.

ЗАКЛЮЧЕНИЕ ВЛАДИМИРА ПАРОНДЖАНОВА
ПО ДРАКОН-АЛГОРИТМУ
АЛЕКСАНДРА ИЛЬИНА

1. Возражение Александру Ильину



Уважаемый Александр Ильин!

Вы, разумеется, имеете право делать выводы, какие
считаете нужным. Но в данном случае Ваш вывод покоится
на неверном основании. Говоря кратко, ошибка заключается
в том, что Вы нарушили «Золотое правило» и построили свою
программу не в виде силуэта, а в виде системы примитивов.
В результате чего ее эргономическое качество значительно
ухудшилось. Получается нелогично: сначала Вы опустили
качество дракон-схемы «ниже плинтуса» (разумеется,
неумышленно, но от этого не легче). А затем говорите,
что качество дракон-схемы низкое.

Подвожу итог: Вы сделали Ваш вывод на основании анализа
НЕДОПУСТИМО УХУДШЕННОЙ (в эргономическом отношении)
дракон-схемы.
Ниже даны пояснения.

2. Примитив — это плохо! В сложных программах
использовать примитивы нельзя!

Для ясности повторю: моя оценка дракон-алгоритма, созданного
Александром Ильиным, отрицательная. Решение, предложенное
Александром Ильиным, НЕДОПУСТИМО.

Начну издалека. Несмотря на большой опыт создания дракон-
схем, я никогда не сталкивался с ситуацией, когда СЛОЖНУЮ
ПРОГРАММУ СТРОЯТ ИЗ ПРИМИТИВОВ. Поэтому у меня сложилось
впечатление о том, что ЗАПРЕТ на построение сложной
программы из примитивов ЯВЛЯЕТСЯ ОЧЕВИДНЫМ. В связи
с этим в своих книгах я не разъяснил должным образом
НЕДОПУСТИМОСТЬ такого решения.

Теперь я понимаю, что ошибся. Запрет на использование
примитивов надо объявить очень громко, гораздо громче,
чем я это сделал. Важность этого запрета следует
специально подчеркнуть и объяснить очень подробно.

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

Например, Александр Ильин пишет:

«Я ведь даже книгу-то не нашёл времени толком
прочитать, не то что все правила соблюдать. Фактически,
только благодаря редактору я и познакомился в какой-то
мере с языком…».

Отсюда я делаю вывод. При первом открытии дракон-редактора
пользователь должен видеть предупреждающую надпись о
запрете работать с примитивами. Чтобы надпись не мозолила
глаза, пользователь может ее удалить, дав указание «Больше
не показывать». Или что-то в этом роде.

3. В чем суть ошибки?

Александр Ильин пишет:

«…я ведь разбил алгоритм на независимые
части-процедуры, которые и оформил в виде примитивов.
Ни в одном из примитивов не встречается более 13 блоков,
не считая "заголовка", "параметров" и "конца" (а если
последовательные действия объединить в "полки", то будет
не более 9 блоков алгоритма на процедуру), так что за
верхний лимит "15" я формально не вышел».

Уважаемый Александр!

Суть неприятности в Вашей фразе «…я ведь разбил алгоритм
на независимые части-процедуры, которые и оформил в виде
примитивов…». Именно этого нельзя делать НИ В КОЕМ СЛУЧАЕ.

Почему? Потому что целостный зрительный образ силуэта
распадается на осколки. Причем связь между осколками
НЕЛЬЗЯ БЫСТРО УВИДЕТЬ ГЛАЗАМИ.
Выявление связи между осколками-примитивами (для читателя,
не знакомого с проблемой, или автора, читающего свою
программу через полгода) требует долгих и мучительных
раздумий, трудоемкого анализа. Это плохо.

Далее. Согласно «Золотому правилу» надо считать число
икон не в одной процедуре, а во всей программе, то есть
ПРОСУММИРОВАТЬ ЧИСЛО ИКОН ВО ВСЕХ Ваших процедурах.
В Вашей программе (см. сообщение
viewtopic.php?p=14681#p14681 )

используются 68 икон. Это намного больше, чем 15.

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


4. В чем преимущество силуэта?

Достоинство силуэта состоит, в частности, в том, что
В СИЛУЭТЕ ЕСТЬ ШАПКА. Шапка играет чрезвычайно важную
роль. Она существенно облегчает понимание дракон-схемы.
Сейчас я приведу пример шапки, а затем продолжу
объяснение.

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

Зацените:

Вот чем хороша визуализация, так это обозримостью. Чтобы понять принципы работы SVN, надо внимательно прочитать неслабую документацию и построить схему в голове. Чтобы там критики ни говорили, а пока текст до конца не прочтёшь, схему в башке не построишь. Блок-схема, как таковая, мгновенно показывает границы - отчего становится легче на душе, а дракон-схема усиливает натиск и показывает "градиент важности" наблюдаемых процессов.

ну можно ещё команды svn вписать...

Может это и не существенно, но я считаю что слово "Конец", кроме как в конечном блоке использовать нельзя. Лично у меня было большое желание не смотреть последнюю ветку.

А что? Три ветки соответствуют типовому паттерну: Initialize, Work, Finalize...
Возможно, так и следует назвать...

По-моему тут из пушки по воробьям:

А может проще? Начать, Поработать, Закончить

Попробуем...Это точно лучшеА как с командами?

Так-так... а воробьи-то крупные бывают....

Да, нагляднее...

(В.Д.)

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

Нет, ни в коем случае. Это смешивание принципиально разного!!

Вы получаете GOSUB Бейсика, ужас какой-то