Недостатки языка ДРАКОН

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

1. Особенность языка подразумевает более сложные способы ввода, редактирования и передачи по сравнению как с плоским, так и, отчасти, насыщенным текстом. Для кода характерны необходимость вырезания, вставки, слияния, поиска и замены по шаблону, что трудно осуществлять с блок-схемами в прямом виде. Частично может быть решено введением текстового представления или гениальными разработками в области программ для работы со схемами.

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

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

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

5. Зашумленность кода. При небольшом изучении, особенно в ряде языков, поток выполнения кода становится очевидным, и его подчёркивание, что может быть и полезным в ряде случаях, здесь не только не вносит дополнительной ясности, но и, наоборот, отвлекает от основной сути кода. Есть неустранимое противоречие в представлении кода для разных применений и разных групп пользователей.

6. Не всем людям представление кода в виде блок-схем, пусть и составленным по дополнительным эргономическим правилам, даёт преимущество в восприятии кода по сравнению с текстом, и возможна обратная зависимость. Многим людям для того, чтобы нарисовать блок-схему, сначала требуется написать код в качестве образца. Так было раньше [0], остаётся и сейчас.
Несмотря на это некоторые по-прежнему считают аксиомой, что хорошие блок-схемы понятней людям. Может быть решено хорошим текстовым представлением, позволяющим бесшовное взаимодействие разных групп разработчиков.

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

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

8. Отсутствие адекватного представления для самой часто используемой в ряде языков разновидности цикла c проверкой условия продолжения перед выполнением тела цикла(WHILE DO). В ДРАКОН необходимо либо удвоить проверку - в начале цикла и в конце каждой итерации, либо вынести тело цикла в побочную ветвь ветвления, нарушая правило самого ДРАКОН - "чем правее, тем реже". Эту оплошность можно охарактеризовать как провал.

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

10. Повышенная сложность распознавания направленности ветвления. В ДРАКОН направление исполнения при истинности условия может меняться в зависимости от того, возле какой ветки был выставлено "Да". Это требует от читателя больше внимания в сравнении с постоянным направлением, как это есть в большинстве языков. Фактически, в ДРАКОН "Да" и "Нет" - это не подсказки для незнакомых с блоком-вопросом, а составные части неявного сравнения логического значения. И если сравнение с "Да" - это тавтология, то сравнение с "Нет" - это аналог отрицания, что становится совсем очевидным, если сравнение провести в явном виде:
НЕ А,
НЕТ = А

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