Как видим, наш алгоритм по сравнению с конкурентным Драконовским стал просто на порядки выразительнее, понятнее и эффективнее для восприятия. Однако так же мы можем увидеть большое количество недостатков, в частности – частое повторение одних и тех же действий, наличие линий пересечения и подсоединения, не эффективное распределение площади диасцены, не эффективное построение самого алгоритма. Частично эти проблемы в Драконе решаются путем создания замкнутых контуров, но это не улучшает понимание алгоритма, ибо противоречит пункту 11.
Что же, давайте попробуем улучшить наш алгоритм путем применения тех же правил. К сожалению, он составлен таким образом, что разбить его на смысловые блоки правильно, с учетом того, что каждый из них может быть использован как подпрограмма – весьма проблематично, так как отдельные команды взаимно пересекаются, поэтому для решения данной задачи мы используем команды адрессного перехода.
Как мы можем видеть, наш алгоритм стал еще более выразителен, при этом он стал проще и меньше, а значит – мы идем в верном направлении.
Что же, осталось только его упаковать в более компактное пространство…
Как видите, наш алгоритм приобрел предельную простоту и понятность, воспринимаемую визуально очень хорошо и позволяющую очень быстро разобраться в его логике. Осталось только добавить текстовые элементы из Драконовского алгоритма для более подробного уточнения задач алгоритма и мы получим окончательный вариант, не оставляющий никаких сомнений в своих преимуществах перед схемами предыдущего поколения.
Мне могут возразить, что создание таких алгоритмов занимает гораздо больше времени и намного проще написать несколько строк текста. Однако, сейчас речь не о настоящем, а о будущем, ведь большинство программистов, думающих, что пишут программу раз и навсегда и понятность кода можно принести в жертву компактности и быстроте написания кода, не задумываются, что всего через 10 – 20 лет компания, заказавшая разработку ПО, может начать переходить на новые концепции, другие библиотеки, прогрессивные технологии или даже на другой тип лицензирования, и тогда уже другому программисту придется либо разбирать имеющийся код, либо, что гораздо вернее – писать все с нуля. Мы же, замедляя разработку в начале, делаем возможным ее эффективно использовать в дальнейшем и тем самым ускорять работу над крупными проектами.
Второе возражение, которое мы можем встретить – это сложность в поиске графических элементов. Но это не совсем соответствует действительности, ведь нам не нужно сажать новых художников и рисовать каждый элемент программы заново – нам достаточно скачать из сети любой уже имеющийся и хорошо объясняющий суть вопроса, и, обработав его, вставить в стандартную библиотеку. Можно сказать так, что все графы и глифы уже давным давно нарисованы, нужно их только стандартизировать и упорядочить.
Предполагаю и третье возражение, что таким образом писать прикладные программы не получится, ведь они не являются последовательностью действий человека, которые легко отобразить графически, но и это является заблуждением. Дело в том, что перед написанием любого алгоритма, каждый программист может описать те или иные абстрактные графы и глифы, которые он использует в своей программе, а другой, который будет разбираться в его программе, таким же образом, ориентируясь по описаниям, заменить их на те, которые понятны ему, и тем самым одним махом преобразовать имеющийся алгоритм в понятный ему. Это решает любые проблемы со сложными абстрактными моделями и понятиями.
0001
…
)))
))) 
