DRAKON.SU

Уважаемый автор.

Я в качестве эксперимента делаю что-то вроде визуальной фронтенд-студии и попробовал реализовать дракон в качестве основного языка визуального программирования (не гибридный ДРАКОН-JavaScript, а чистый Дракон со специальным движком обработки данных, похожим на смесь Excel и Smalltalk).

Столкнулся с некоторыми затруднениями, некоторые из которых разрешить было тривиально:

— Diff, merge и в целом просмотр истории изменений — как и для любого ориентированного графа эти проблемы относительно легко решаются (при определённых усилиях можно даже полностью снять с программиста задачу по разрешению конфликтов, но, разумеется, никакой git тут неприменим и понадобится CVS, основанная на других принципах).

— Try-catch — это тоже можно решить, хотя уже с изменением стандарта языка (нужно модифицировать икону ветки, чтобы она могла допускать ветвление при ошибке внутри ветки и переходить к веткам catch и finally).

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

Дракон не умеет передавать функции как данные, поэтому в своей студии мне пришлось сделать гибридный визуальный язык — для «атомов», то есть элементарных функций используется Дракон, а вот для передачи сообщений/функций используется нодовый редактор — примерно такой-же, как Blueprints в Unreal Engine. А такая структура уже не так эргономична, как чистый Дракон.

Я думаю, что Дракон имеет в себе потенциал стать языком разработки, который сможет сделать программирование доступным для большинства людей, но для этого стандарт нужно серьёзно дополнить и переработать

Было бы интересно посмотреть на примеры программ.

чуть позже создам тему со своими наработками

Здравствуйте. Вы очень давно, 3 года назад, писали мне по поводу применения языка ДРАКОН, когда я публиковал на форуме идею использования его во фронтенд-конструкторе.

Хочу сообщить, что идею я не забросил, и не заброшу. Я потратил немало свободного времени как на размышления, так и на проверку концепций практического программирования.
А особенно много времени убило у меня изучение графического программирования - webGl, webGPU. Чтобы среда была чрезвычайно быстрой и позволяла комфортно редактировать огромные холсты с реальными программами (считаю, что идея бесконечного холста, как в редакторе Figma - самая наилучшая и для графического программирования) и кучей дополнительных виджетов - вроде предпросмотра объектов и компонентов.

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

Это наихудшая идея. Если размещать всё в одном месте, то вы очень быстро столкнётесь с пределом Дойча (https://en.wikipedia.org/wiki/Deutsch_limit).

Предел Дойча — это афоризм об информационной плотности визуальных языков программирования , созданный Л. Петером Дойчем , который гласит:

Проблема визуального программирования заключается в том, что на экране одновременно не может быть более 50 визуальных примитивов. [ 1 ]

Термин был придуман Фредом Лакиным после того, как Дойч сделал следующий комментарий на лекции Скотта Кима и Уоррена Робинетта о визуальном программировании : «Ну, это все прекрасно и замечательно, но проблема с визуальными языками программирования в том, что на экране одновременно не может быть более 50 визуальных примитивов. Как вы собираетесь написать операционную систему?» [ 1 ] [ 2 ] [ 3 ]

Примитивы в визуальном языке — это отдельные графические элементы, используемые для построения программы, и наличие большего их количества в одно и то же время позволяет программисту считывать больше информации. Этот предел иногда приводится в качестве примера преимущества текстовых языков над визуальными, [ 4 ] указывая на большую плотность информации текста и создавая трудности в масштабировании языка. [ 5 ] [ 6 ]

Однако критика этого ограничения заключается в том, что неясно, существует ли аналогичное ограничение в текстовых языках программирования; [ 1 ] и что ограничение можно преодолеть, применив модульность к визуальному программированию, как это обычно делается в текстовом программировании.

Смотрите также
Когнитивные измерения нотаций
Закон Конвея

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

> считаю, что идея бесконечного холста, как в редакторе Figma - самая наилучшая и для графического программирования

Это наихудшая идей. Если размещать всё в одном месте, то вы очень быстро столкнётесь с пределом Дойча (https://en.wikipedia.org/wiki/Deutsch_limit). По этому нарисовать сколь либо большую программу в такой среде у вас не получится.