Фредерик Брукс в 1986 году написал статью «Серебряной пули нет», где показал, что ряд средств, на которые в то время возлагались большие надежды, не станут «серебрянными пулями», т.е. средствами, которые повысят продуктивность программиста на порядокв ближайшее десятилетиепосле написания статьи. Одним из таких средств было визуальное проектирование. Приведу достаточно обширную цитату.

> -- Цитата:
> Излюбленной темой докторских  диссертацийв   программной    инженерии    является   графическое,   или    визуальное,программирование - применение компьютерной графики в разработке программногообеспечения.[9] Иногда перспективы такого  подхода основываются на  аналогии спроектированием СБИС, в котором компьютеры играют такую большую роль. Иногдатакой  подход  обосновывается,  исходя  из  того,  что  блок-схемы  являютсяидеальным  материалом  при проектировании программ. Имеются  мощные средствадля создания таких блок- схем.     Ничего убедительного и удивительного из этих попыток пока не вышло, - ия уверен, не выйдет.     Во-первых,  как  я всюду доказываю,  блок-схема является  весьма слабойабстракцией структуры программы.[10]  Лучше всего это видно из попыток Беркса,фон Неймана  и Гольдстайна  снабдить  свой предполагаемый  компьютер  крайненеобходимым управляющим языком высокого уровня. В  том жалком виде -  многиестраницы   соединенных   линиями  прямоугольников,  -   в  котором   сегодняразрабатываются блок-схемы,  они доказали,  в сущности, свою  бесполезность:программисты рисуют их после, а не до создания описываемых ими программ.     Во-вторых,  сегодняшние  экраны  имеют  слишком  мало  пикселов,  чтобыпоказать  целиком и с достаточным разрешением сколько-нибудь подробную схемупрограммы. Так  называемая "метафора рабочего  стола"  становится  метафорой"сиденья  самолета". Всякий,  кому приходилось  листать пачку бумаг,  будучистиснутым  двумя корпулентными  соседями, почувствует  разницу: одновременноможно  увидеть очень немного. Настоящий рабочий стол позволяет  обозревать ипроизвольно  выбирать множество бумаг.  Более того, в порыве  творчества  неодин программист или писатель предпочитал рабочему столу более вместительныйпол.   Аппаратным   технологиям  нужно  сделать  очень  большой  наг,  чтобыпредоставляемый  экранами  обзор  был  достаточным для задач  проектированияпрограмм.     Если  обратиться  к  основам,  программное  обеспечение  очень   трудновизуализировать,  как  я  доказывал  это  выше.  Составляем   ли  мы   схемыуправляющей логики, вложенных областей,  видимости переменных,  перекрестныхссылок переменных, потоков данных, иерархических структур данных или чего-тоеще,  они отражают лишь одно изменение  взаимодействующих запутанным образомчастей  программной  системы.  Если  наложить  одна  на  другую  эти  схемы,отражающие  взгляд  с  различных  точек  зрения,  трудно  извлечь  из  этогокакую-либо  общую точку зрения.  Аналогия с интегральными схемами вводит,  всущности,   в   заблуждение:   конструкция  микросхемы  представляет   собоймногослойный  двумерный  объект,   геометрия   которого  отражает  сущность.Программная система не является таким объектом.

Таким образом, Брукс приводит два аргумента: блок-схемы как средство помощи в разработке програм излишни и имевшиеся в то время мониторы неудобны для графической разработки программ. Ссылка [10] косвенно отсылает к главе 15 книги «Мифический человеко-месяц», где Брукс показывает, что хорошо написанная программа столь же выразительна, что и блок-схема.

Ответить на оба аргумента можно, наверное, так. Рисовать блок-схему алгоритма до написания программы на высокоуровневом ЯП излишне, равно как использовать её для документации кода на том же высокоуровневом ЯП. Но если есть компилятор/интерпретатор блок-схем, т.е. не требуется дублировать схему текстом программы, то блок-схема имеет право на существование. А что касается второго аргумента, сейчас разрешение 320×200 пикселей можно встретить разве что на мобильниках, разрешения экрана вполне должно хватать.

Мой вывод:программирование путём рисования блок-схем — вполне приемлемый подход, наравне с другими видами программирования. Наверное, стоит поковырять тот же Дракон.

Но:хорошо помню один пример. На кафедре, где я учился один аспирант разрабатывал прошивку для ПЛИС (кафедра делала оборонный заказ). Поначалу он использовал средства визуального программирования в САРП Altera Quartus — рисовал принципиальные схемы — квадратики и встроенные примитивы (И, ИЛИ, НЕ и другие) соединял линиями. Потом оказалось, что такой код нагляден, но трудносопровождаем, т.к. при изменении схемы приходится все эти квадратики и линии передвигать. Перешёл на программирование наVerilog’е.