Почему Визуальное Программирование не смогло

https://zen.yandex.ru/media/anosistem...

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

И очень долгое время, в двадцатом веке, все что люди могли делать - это программировать компьютеры при помощи перфокарт. А это сложный процесс.

Единственный язык, напрямую выполняемый ЭВМ — это машинный язык- код. Изначально все программы писались в машинном коде, но сейчас этого практически уже не делается. Вместо этого программисты пишут исходный код на том или ином языке программирования, затем уже он транслируется в машинный код.
Прорыва до сегодняшнего дня не случилось
Прорыва до сегодняшнего дня не случилось

Для моего коллеги, как-то было открытием узнать, что его любимый терминал в котором он пишет скрипты в Linux - Bash (популярная разновидность командной оболочки UNIX) тоже всего лишь программа. Многослойные пироги из интерфейсов и представлений везде встречают нас в мире компьютеров. Даже текстовые интерфейсы - это всего-лишь слой над машинным кодом.
Визуальное программирование

Манипулирования графическими объектами вместо написания её текста часто представляют как следующий этап развития текстовых языков программирования. Наглядным примером может служить утилита Визуальный Pascal или Microsoft Visual Studio, где редактируются графические объекты и одновременно отображается соответствующий текст программы. Но эти среды и инструменты не дают полного перехода к визуальному программированию. Здесь отдана на откуп только часть с графическими интерфейсами.

В последнее время визуальному программированию стали уделять больше внимания — в связи с развитием мобильных сенсорных устройств.

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

Похожий инструмент от Google под название Blocky

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

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

Схемы просты, пока они маленькие. Я сам проектировал некоторые штуки в виде майндмапов, и они пригодны к работе только пока маленькие. Читаемость больших схем ужасна.

Текстовый вид удобен тем, что для него выработаны некоторые приемы декомпозиции. Ну например, можно легко назвать две парадигмы — ООП и функциональное программирование. И мы знаем, на какие части надо разбивать, и как их компоновать друг с другом (шаблоны проектирования, или монады).

В случае диаграмм ничего из этого нет.

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

В некоторых областях графическое программирование может применяться, а то и быть самым удобным инструментом (например в программах типа Blender).