MetromDouble писал(а):
Уважаемый автор.
Я в качестве эксперимента делаю что-то вроде визуальной фронтенд-студии и попробовал реализовать дракон в качестве основного языка визуального программирования (не гибридный ДРАКОН-JavaScript, а чистый Дракон со специальным движком обработки данных, похожим на смесь Excel и Smalltalk).
Столкнулся с некоторыми затруднениями, некоторые из которых разрешить было тривиально:
— Diff, merge и в целом просмотр истории изменений — как и для любого ориентированного графа эти проблемы относительно легко решаются (при определённых усилиях можно даже полностью снять с программиста задачу по разрешению конфликтов, но, разумеется, никакой git тут неприменим и понадобится CVS, основанная на других принципах).
— Try-catch — это тоже можно решить, хотя уже с изменением стандарта языка (нужно модифицировать икону ветки, чтобы она могла допускать ветвление при ошибке внутри ветки и переходить к веткам catch и finally).
Однако, есть концептуальные сложности — ориентированность Дракона на процедурное и автоматное программирование приводит к очень громоздкому графу выполнения, когда мы встречаемся с задачей описания асинхронных потоков данных, на которых построены веб-приложения.
Дракон не умеет передавать функции как данные, поэтому в своей студии мне пришлось сделать гибридный визуальный язык — для «атомов», то есть элементарных функций используется Дракон, а вот для передачи сообщений/функций используется нодовый редактор — примерно такой-же, как Blueprints в Unreal Engine. А такая структура уже не так эргономична, как чистый Дракон.
Я думаю, что Дракон имеет в себе потенциал стать языком разработки, который сможет сделать программирование доступным для большинства людей, но для этого стандарт нужно серьёзно дополнить и переработать