DRAKON.SU

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

Ссылки на мои схемы
https://docs.google.com/drawings/d/1-Wb ... sp=sharing
https://docs.google.com/drawings/d/1TBy ... sp=sharing
https://docs.google.com/drawings/d/1hwR ... sp=sharing
https://docs.google.com/drawings/d/1dGA ... sp=sharing

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

Нет. Понятия оптимальный и эргонимичный различаются и описывают разные свойства алгоритма.

1. Оптимальный - скорость выполнения и расход памяти. Чем меньше, тем лучше.
2. Эргономичный - понятный для читателя.

Разумеется, можно быстрый алгоритм описать понятно. А можно медленный - непонятно.

В плане эргонимика у вас нарушены 2 правила Дракона:

1. Пересечение маршрутов.
2. Нестандартные обозначения икон.

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

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

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

Насчет пересечений я и так знал. Разбить алгоритм на ветки наверно не получиться, какие тут выбрать ветки, как разделить алгоритм на смысловые части, если они тут вообще есть.
Тут есть 2 варианта выхода из цикла.
1. Выход из цикла в начале, после проверки двух условий. Реализовано сейчас.
2. Выход из цикла внутри самого цикла при наступлении определенных условий с использованием оператора break.
И какой из этих вариантов лучше.

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