Всем привет! И доброй пятницы!

У меня в голове назрело несколько полуриторических вопросов и соображений.

— Почему лучшие умы буквально с первых дней создания компьютеров бьются над проблемой создания языка, позволяющего проектировать программы по аналогии с созданием электронных схем, и всё без толку???

— Почему "электронщики" могут:
— Создавать из электронных компонентов платы;
— Оттестировав платы, не забивать себе голову деталями их реализации;
— Создавать из плат крейты;
— Оттестировав крейты, считать их работающими "чёрными ящиками";
— Создавать из крейтов — стойки, и т.д....

...а программисты не могут?
// Оффтоп: Моё основное место работы — лаборатория экспериментальной ядерной физики, и я каждый день
// вижу то, о чём говорю. Стили работы инженеров-разработчиков электронной аппаратуры и
// программистов разнятся кардинально. Причём не в пользу последних.

— Почему современное программирование по-прежнему напоминает смесь шаманства, искусства и кулинарии нежели инженерную дисциплину?

— Почему единожды написав и оттестировав программный компонент, процесс повторного использования оного во всех дальнейших проектах схожей тематики доводит программиста до кровавого геморроя? Особенно в С++!

— Не кажется ли вам, уважаемые господа, что концепция программы в виде последовательно выполняющихся инструкций годится далеко не на все случаи жизни?
// Оффтоп: ФП не предлагайте — я прагматик

— Не лучше ли использовать flow-driven-programming для больших, и тем более распределённых, программных систем.
// Да, я конечно понимаю, что серебрянной пули не существует, и все существующие классы задач данным методом не решить.
// Какие задачи удобно решать: системы DSP, SCADA, АСУТП, системы диагностики, сигнализации, и т.п.



К чему вообще всё это: хочется просто-напросто поднапрячься, да и изваять модульную, повторно-используемую и удобную (на первых порах — хотя бы для себя) "потокоцентричную" архитектуру разработки приложений.

Из коммерческих реализаций данной идеи стОит вспомнить LabVIEW. Очень, надо сказать, популярный язык в узких кругах, и недешёвый при том.

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

Есть идеи, как сделать так же, да лучше. СтОит ли браться?

PS. Понимаю, что последний вопрос самый риторический.