Когда я еще только начинал изучать UML, а это было очень и очень давно ему пророчили альтернативу всем языкам. Причем пророчили в “ближайшем обозримом будущем”. Что, мол, используя UML вы вскоре сможете наяривать полноценные программные продукты. Но вот только “воз и ныне там”. Ничего хорошего из этого, естественно, не вышло. Потому как описать все языковые абстракции просто иногда слишком сложно. Мало того, много случаев, когда это не сопоставимо по трудовым затратам. Поэтому ни о каких “заменах” речи быть не может. Только как альтернатива для совсем уже простых проектов.

P.S. Основными задачами UML все же стали проектирование и описание, но никак не замена. Поэтому про “будущее графических языков” мы слышали и не раз

ZerG
Из конструктра с ограниченным количеством кубиков я смогу собрать только возможные определености - выкручиваясь количеством и размером кубиков.

Имея конструктор кубиков - я могу создавать кубики по задаче.
Стоит ли развивать мысль дальше?

Стоит. В схемотехнике все именно так и обстоит(ну если ПЛИС не считать, хотя его можно как конструктор кубиков зачесть). И ничего, живут.

> Как должен осуществляться контроль версий, пулл-реквесты, патчи, разрешение конфликтов?

Точно так же как и до этого. Никаких особых проблем я здесь не вижу.

> Поэтому ни о каких “заменах” речи быть не может. Только как альтернатива для совсем уже простых проектов.

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

Rodegast
Ну как-бы ДРАКО для не совсем простых проектов применяется… Так что не соглашусь.

Ну как бы я вообще не вижу его в списке языков. Пусть даже какое-то там 50 место. Поэтому не соглашусь все же я. Возможно умельцы его и применяют для “очень сложных проектов”, но количество этих умельцев настолько мало, что о полноценном применении сего решения все же можно поспорить. Ну и трудоемкость никто не измерял, верно? Видел умельцев, которые на UML умудрялись всякие вещи безумные писать, а потом получать рабочий код через генератор.

P.S. Вот только рефакторинг кода, который этот генератор выдает после “сложных проектов” я никогда не видел

Rodegast
Точно так же как и до этого.

До этого я работал с текстом.

Rodegast
Никаких особых проблем я здесь не вижу

А я вижу. Как вы будете пользователю показывать различие версий и редактировать конфликты? Вы же понимаете, что три строки кода могут изменить блок-схему до неузнаваемости.

> До этого я работал с текстом. Как вы будете пользователю показывать различие версий и редактировать конфликты?

Схемы описываются текстовыми файлами (например xml или как сейчас drt) по этому у git-а проблем с этим не будет. Обычного diffa-а будет недостаточно, будет нужна программка которая сможет визуализировать различия в схемах. Но это не проблема, такое сделать вполне реально.

> Ну как бы я вообще не вижу его в списке языков. Пусть даже какое-то там 50 место.

Это потому что будущее ещё не настало

Что-то как-то медленно оно настает. Причем померло уже масса графических языков. В топ не выбрался не один. Или будущее очень туманно или где-то просчет в Вашем прогнозе

Rodegast
Схемы описываются текстовыми файлами (например xml или как сейчас drt) по этому у git-а проблем с этим не будет. Обычного diffa-а будет недостаточно

Что и требовалось доказать. Шаг в сторону от красивой теории, и вот уже нужно знать язык.

> Шаг в сторону от красивой теории, и вот уже нужно знать язык.

Схемы конечно же делаются при помощи визуальных средств разработки + визуальный diff. По этому всё нормально

Rodegast
Обычного diffa-а будет недостаточно,

На самом деле при разработке систем автоматики и теплогидравлических сетей задание данных в виде схем очень распространено. Более того, кодогенерация из схемы кода на c/asm рекомендуется всякими ИСО-МЭК.

Изнутри графическая работа выглядит так.
Десятки человеко-лет тратятся на разработку всяких diff и граф редакторов. Непрерывно многие десятки людей ведут работы преобразованию отработанных решений из одного проекта в другой. Люди перерисовывают схемы в новом стиле, переобозначают коннекторы и т.п. В рамках одного проекта генерация новых версий идет с темпом обновление раз в две недели - месяц. Это требует сравнения десятков тысяч чертежей. git, diff и прочее практически не используется, поскольку часть данных в схемах часть в оракле часть исполнитель даст только за деньги. Поэтому на сравнение все забивают, поскольку это неподъемная задача. Зачастую это приводит к тому что ошибки проекта гуляют кругами между организациями несколько лет.
Отдельная отрасль - распознавание схем и конвертация их в вид пригодный для других систем. Это работает, но оставляет за собой тоже кучу ручной работы.

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

Из статьи про дракон “Это обстоятельство ставит непреодолимый барьер для непрограммистов, то есть специалистов, работа которых связана с алгоритмами, но которые не имеют резерва времени, чтобы научиться выражать свои профессиональные знания в форме алгоритмов и программ”. Это абсурд. Профи в алгоритмах не может найти пару недель на то чтобы выучить язык? Может и матанализ надо перестать изучать на первом кусрсе, а то сложно больно?

Сама идея визуального программирования (именно программирования) к настоящему времени, по моему мнению нанесла такой вред, что ее можно приравнять к патологическому пристрастию к компьютерным играм. В вузах пора читать лекции о вреде визуального программирования, а компании которые рекламируют этот подход возможно надо преследовать в законодательном порядке, за распространение технологий противоречащих научной организации труда.