Комментарии 27
Визуальное программирование vs DSL
Это не взаимоисключающие понятия, так как среда визуального программирования вполне способна генерировать код на DSL.
Да, в принципе так и должно быть. Но тут дело в том, что многие среды визуальные программирования (разные Low-code и No-code конструкторы) игнорируют это, не создают прослойки в виде DSL, а сериализуют все или в XML, или в какой-нибудь бинарный формат. Возможно, разработчики считают, что никто не будет править вручную DSL.
Вот вот, поэтому пункт "Возможность копирования/вставки, поиска и замены по текстовым значениям, генерации кода" несколько сомнителен да и далее автор сам же пишет
Следует отметить, что DSL и визуальное программирование не являются альтернативами друг друга. При правильном подходе визуальный конструктор может и должен генерировать DSL. В качестве такого языка часто используется XML. Однако, читабельность XML оставляет желать лучшего.
Редактировать XML так же возможно со всеми копированиями и вставками - хотя признаю, что делать это сложнее, чем в plan-text представлении DSL языка. Хотя тут многое так же зависит от редактора XML.
Но хочу так же сказать - что правильная IDE (или визуальный конфигуратор) могла бы сделать этот процесс ещё более удобным, чем plan-text редактирование - но таких визуальных редакторов я ещё не встречал - просто эта тема практически не развивается, а вот plan-text IDE в XXI веке развивались очень активно.
Но моё мнение такое - правильная NoCode (и тем более LowCode) система обязательно должна иметь и текстовое представление структуры алгоритма (в идеале в виде DSL описания, и в идеале так его и хранить, при необходимости создавая структурированный индекс поиска), имея лишь возможность визуализировать и редактировать его визуально!
Поддержка системы контроля версий. В визуальном программировании значительно менее удобно следить за изменениями в логике программы и решать конфликты в коммитах.
Вот этот пункт остался не совсем ясен. Вообще-то сравнивать структурированный алгоритм (в виде графа) куда проще, но тут нужен свой специализированный инструмент сравнения, чем plan-text - но если речь идёт о стандартных инструментах, которые исторически ориентированы на текстовое сравнение - то да - тут возникают некоторые сложности - но это не более чем проблема либо инструментов сравнения либо того, что даже визуальный алгоритм не хранится как текст (не обязательно даже DSL)
В итоге - визуальное программирование хорошо тогда, когда за ним стоит и plain-text представление!
Но тут ещё один момент - лично я не думаю, что пользователи массово будут заниматься NoCode (и тем более LowCode) разработкой. У пользователей своих дела хватает. По своей практике чаще всего пользователям проще свалить даже банальную первичную настройку ПО на любого IT-шника доступного в организации. Всё-так пользователи слишком ленивы, чтобы что-то конфигурировать. Максимум на что их хватает - это на формулы в EXCEL. Но, безусловно, среди пользователей есть исключения, и их не так уж мало.
использует обычные слова вместо специальных символов, то порог вхождения значительно снижается (вот пример одного из таких языков).
Ну я бы не назвал такой язык удобным для восприятия. Даже ЯП 1С и то попроще воспринимаемся. Пользователям этот ЯП 100% не годится.
получив при этом IDE значительно превосходящую по возможностям тот же Конфигуратор 1С.
Нашли с чем сравнить - конфигуратор 1С практически не развивался уже более 10 лет - да и 20 лет назад он был не таким уже продвинутым, чтобы было на что ровняться даже тогда. Более менее продвинутые IDE это Visual Studio и Rider/IDEA - да и то - прогресс у них только последние годы, да и сейчас они ещё далеки от совершенной IDE - но постепенно движутся с ней.
Автор та же упустил ещё два метода программирования:
Командный - когда программа полностью редактируется путём отправки команд редактору (вроде бы на Хабре была статья на эту тему, но навскидку не нашёл, может я и ошибаюсь - но идея вполне интересная, особенно на фоне стремления некоторых к переходу на голосовое управление и редактирование с применением возможностей ChatGPT) - тут могут быть как команды к plain-text так и к визуальному представлению
Схематичный - в принципе это подвид визуального (но я считаю, что его стоит выделить как отдельное направление) - когда алгоритм строится в виде блок-схем на плоскости (в 3D ещё не видел, хотя с развитием VR этот вариант вполне может получить развитие)
А вообще статья получилась ну очень маленькая и очень скромная - по сути тема так и осталась не раскрытой ни с точки зрения постановки проблематик, ни с точки зрения проработки их решения :-(
Вообще-то сравнивать структурированный алгоритм (в виде графа) куда проще, но тут нужен свой специализированный инструмент сравнения
Вот я себе слабо представляю такой удобный инструмент. Да и, если честно, никогда особо не видел таких, которые помимо изменений еще и merge бы позволяли делать. Возможно его вообще невозможно создать.
По своей практике чаще всего пользователям проще свалить даже банальную первичную настройку ПО на любого IT-шника доступного в организации
Тут в целом согласен. Платформа low-code в данном случае больше нужна, чтобы именно сделать из пользователя IT-шника. Однако, возьмем, например, одну из популярных low-code платформу с визуальным программированием. У них на Github 25.6К звезд. Вряд ли это все вот трушные программисты. Значит видимо и пользователи что-то делают.
Примеры есть: jasper report (Studio). и визуализация нормальная и когда надо спокойно можно перейти в код и сделать массовую поиск замену.
"командный"
-так и вспоминаются редакторы типа EDI из RSX-11.
Честно скажу — такое себе было удовольствие… ну его...
Прогресс движется по спирали так что всё ещё может вернуться под новым соусом, особенно в рамках LowCode, умных генераторов алгоритмов на основе ChaptGPT, а ещё и с голосовым управлением! И тут много ещё может завесить как от уже сложившихся привычек, так и от особенностей проработки юзабилити - это как сравнение с особо эргономичными клавиатурами в иной раскладке или как вот был сенсорный ввод ещё в конце XX века - но он был не удобен и тут пришёл Стив Джобс и показал как надо!
Но всё же, я просто упомнил что есть такой подход, не делая оценок его удобства в нынешних реалиях, а автор его упустил из анализа
Из виртуального опыта дипломного проектирования: Было необходимо разработать систему управления инсинератором, обычно такие вещи делают на плк, а каждый плк должен поддерживать языки стандарта iec, но как основной предполагается язык fbd, что является своеобразным адом для тех кто большую часть времени пишет "в столбик" и функциями, в итоге пришлось делать на паскалеподобном dsl под названием scl и делать глобальные переменные текущих состояний, потому что это было проще понять, чем на функциональных блоках.
Автору есть смысл погуглить про Р-схемы Глушкова и Вельбицкого (1976?), системы Графит-Флокс и ДРАКОН Паронджанова (публичная часть). А также системы программирования на ДРАКОН от Тышова. Откроете для себя много нового, в т.ч. и то что популярные UML диаграммы это просто "утечка из СССР". ;)
Что не так с комментарием? Кто минусовал пояснить способен или так, отметиться? Всего лишь посоветовал поизучать историю вопроса. Она гораздо древнее, чем кажется автору.
ткнул минус выше и плюс ниже и обнаружил что тут голос поменять нельзя... прикольно
Так зачем тыкать-то?!? Можете пояснить за что минус, интересно жеж..
Визуальщина гораздо древнее, чем кажется. Тышовский ДРАКОН позволяет писать алгоритм Заказчику (Архитектору, Электронщику, что сваял схему и т.д.), затем оно попадает к Программисту, который переложит это на свой язык и код появится под капотом. Затем оно может попасть к Тестировщику и под капотом появятся его замечания.. очень удобно и применяется в серьезной разработке.
Делал на его базе генерацию кода для Ардуино, когда сын обучался программированию в свои 8-9-10 лет. Достаточно удобно. Сейчас, думаю там появились ещё ИДЕ, и получше наверное..
визуальщина гораздо тупее, чем кажется.
Вся команда дураконщиков не осилила сделать инструмент. на своем языке, "улучшающем работу ума", "моделирующеем жизнеритмы", и прочем.
все эти потуги "написания алгоритма заказчиком/архитектором/инженеромнежелающимпереучиваться" — это тупиковая вещь. и ни в какой разработке (а уж тем более серьезной) не применяется. ее удел — говнокодинг для начинающих идиотов. когда человек перестает либо быть начинающим, либо идиотом — он звязывает с дураконом, и начинает пользоваться нормальныит инструментами.
Я наблюдаю за Паронджановым и Тышовым уже лет 17… они просто органически (и уже и в силу возраста) неспособны к программированию… зато у них есть "почему мудрец похож на обезъяну", "почему врачи калечат пациентов", "жизнеритмы и мыслеритмы", "программирование без программистов", "исчисление икон" и всё такое. Типа инфоцыган, только "инфоцыгане-интеллектуальные инвалиды".
(я не минусовал, но считаю, что минусуют более чем заслуженно.)
Спасибо за развернутый ответ, мне на самом деле любопытны возражения, ибо писал уже что применял эту визуальщину в процессе обучения своего сына в 8-10 лет. Книжки Паронджанова по алгоритмам зашли на ура, и смотреть как ребенок сам программирует собственоручно сделанного робота - паука и учит его переставлять ножки, и даже смотрит как заставить это бегать прыжками, оно того стоит.
Кмк, то о чем Вы пишете, это попытки применить инструмент за границами его назначения. Точно также как находятся питонщики, которые пытаются оборачивать матрицы, поражаясь как пожираемым ресурсам, так и времени исполнения.
ДРАКОН, насколько читал в то время, особенно Тышовский, писан для конкретного КБ, где-то в Мурманске, где и применяется. Вся система Графит-Флокс - это тот инструмент на котором построили Буран в свое время. ДРАКОН - просто "публичная часть" по сию пору, не смотря на то, что часть утекла в постперестроечное время и теперь это UML.. но это так, за что купил, сам не работал в этой системе полноценно. Не защиты для, а как пример применения молотка вместо микроскопа и наоборот.
Чистому программированию (универсальному, обрабатывающему ПО) визуальщина не нужна ни в одном глазу. Это к вопросу об "исчислении икон" и "мыслеритмах". А вот для embded, где работает сразу несколько дисциплин: схемотехник, что ваяяет плату управления, программист, который обеспечивает алгоритмы снятия показания и управление, заказчик которому надо чтобы оно взлетело и не куда попало .. вполне удобно. На нашей практике робототехнического роста ДРАКОН оставил свой след.
Третье место по России (могло быть и первое) - стоит много. И там - визуальщина.
вся система Графит-Флокс — это тот инструмент на котором построили Буран в свое время.
я у Паронджанова лет 12 назад спросил — "как же вы делали программы на драконе, если у вас не было инструментария?" и он честно ответил: "нарисовали на бумажке и отдали на кодирование программистам". Так что роль этого в программе Буран сильно преувеличена. Да и про текущее применение "графит-флокса" кто-то рассказывал (или тут, или на обероне) — если вкратце, то "делают вид, что пользуются", и с нетерпением ждут, пока кто-то из начальства наконец уйдет на пенсию и не будет мешать пользоваться нормальным инструментарием. Ну и графит-флокс появился только в 90-х, уже после похорон Бурана, поэтому никакого отношения к бурану он не имеет. совсем. Равно как и к UML — цели и история разработки UML известны, дураконом там и не пахнет
применял эту визуальщину в процессе обучения
Могли бы и обычнными блок-схемами пользоваться — ничуть не хуже. Или скретчем — он значительной части детей
даже получше заходит.
А вот для embded, где работает сразу несколько дисциплин
и для эмбеддинга сложнее мигания светодиодом дуракон тоже не нужен. совсем.
я у Паронджанова лет 12 назад спросил — "как же вы делали программы на драконе, если у вас не было инструментария?" и он честно ответил: "нарисовали на бумажке и отдали на кодирование программистам". Так что роль этого в программе Буран сильно преувеличена.
Не работал с ним, но работал недолгое время в Новосибирском ИТМП, где считали Буран и как раз в тот период. Общался с тамошними д.т.н, слышал несколько иное, но у меня были иные задачи, туда меня - студента не пускали.
то "делают вид, что пользуются", и с нетерпением ждут, пока кто-то из начальства наконец уйдет на пенсию и не будет мешать пользоваться нормальным инструментарием.
Вполне допускаю, ибо то что видел краем глаза было "для тех времен" вполне на уровне и может даже "впереди планеты всей" и сомневаюсь, что это тащили вперед в развитии.
Ну и графит-флокс появился только в 90-х, уже после похорон Бурана
кмк сильно старше. Также как мало кто верит в то, что в 1979 году я работал на ИДЕ для фортрана2 в НГУ в терминальном классе аж на 8 терминалов для Минск-222М, у которого всей оперативы было .. 6 килослов. А ведь было! Даже цветной графический дисплей со студенческими шутками в виде программ babuby.. :)
Могли бы и обычнными блок-схемами пользоваться — ничуть не хуже. Или скретчем — он значительной части детей
даже получше заходит.
Ну .. кмк, ДРАКОН и есть блок-схемы (собственно они и вышли из Р-технологии) переложенные на процесс программирования. Там изминений миниум, и в общем-то в сторону "чистой архитектуры" .. или наоборот, если смотреть что было раньше. :)
Скретч был недоступен, ибо Ардуина, а не Лего. Многое собирал здесь, там есть и про те соревнования: https://community.alexgyver.ru/threads/dlja-detej-kak-lego.1398/ если любопытно.. Кроме ДРАКОН нам хорошо зашел Ardublock, даже форкал репу и вносил туда правки по размеру поляны..
слышал несколько иное
слышать можно что угодно, но факт остается фактом.
Вполне допускаю, ибо то что видел краем глаза было "для тех времен" вполне на уровне
в программной инженерии америкосы к тому времени давно уделали СССР. не потому, что они умнее — а потому, что осознали кризис ПО и немного поменяли подход. Так что "на уровне " могли быть какие-то единичные экземпляры, не составляющие системы.
кмк сильно старше
Нет. 1992 или 1994 — и паронджанов говорил, и где-то на картинках этого флокса было.
Ну а в терминалах были свои мозги, это не монитор. У СМ-ок тоже не сильно много памяти было, однако тоже терминальные классы были
Ну… кмк, ДРАКОН и есть блок-схемы (собственно они и вышли из Р-технологии)
Ну в общем да, улучшенные блок-схемы. Только с претензиями на "язык".
А от Р-технологии есть два отличия: 1) блок-схемы — это "граф, нагруженный по вершинам", а Р-технологии — "граф, нагруженный по дугам". 2)Они хотя бы работали — для них было реально разработано ПО, стандарт, и их пытались применять.
Скретч был недоступен, ибо Ардуина, а не Лего.
Был даже эмулятор ардуины со скретчем (правда, недоделаный, но как-то работал). Но у меня сын плюнул на эту каку и начал писать по-человечески. Да, на робототехнике у него тоже было и первое место и второе, потом ему надоело, и он забил на "железо".
Мой тоже забил, но не давно, таки достал Ардуинку и что-то там периодически ковыряет..
Из статьи Вельбицкого:
В науке и практике есть два вида графов (схем) граф, нагруженный по дугам, например, сетевые графики, и граф, нагруженный по вершинам , например, блоксхемы ISO 5807, SDLдиаграммы, сеть Петри, диаграммы Джексона, синтаксические схемы Вирта и т.д. В практике программирования большее распространение получил граф, нагруженный по вершинам, хотя по мощности представления информации оба эти способа эквивалентны. Предлагается технология программирования, использующая в основном графы, нагруженные по дугам, которые изображаются только с помощью горизонтальных и вертикальных линий. Идея этих графов наглядно изображена на рис. 1. Такие графы названы Рсхемами, а основанная на них технология Ртехнологией программирования [13 ]
Не вижу чем одно лучше другого. Да, Паронджанов просто поставил Р-технологию торчком, только и всего. Сами разработки - "конец 70-х"..
да читал я эту статью. ничем одно другого не лучше. кроме одного — Р-технологии не требовали графики, поэтому они и заработали.
Но оказалось, что смысла что в том, что в другом — крайне мало.
Более-менее дружелюбные IDE начали появляться уже в 80-х, языки изменились, программированию в школах начали учить с 1985, и нужда в извращениях отпала.
Но, тем не менее, конец 70-х не одно и тоже что 90-е, это с одной стороны. А с другой, наличие трех слоев представления (даже 4-х, а не только код на языке) отсутствует даже сейчас в современных ИДЕ.
А там ещё есть "фичи" по единому хранению имен (переменных, функций и т.д.) в единой БД .. как раз "подсистема "флокс" .. чего появляется только сейчас и то, в рамках одного проекта ИДЕ способны вести подсказки.. а в рамках всего гит-репозитория корпоратива? ;)
ага, все переменные глобальные, разделения и контроля доступа нет. Хорошо, хоть типизация есть.
можно еще вспомнить способ "именования"…
да там с какой стороны не посмотри… На фоне того же ПРОЛ-2 70-х годов, который оно автоматизировало, может и смотрится неплохо. А по современным меркам...
Не, я это дерьмо даже палочкой тыкать не буду....
Ну .. натягивать сову из Прошлого на современные возможности железа можно, но, кмк, не продуктивно. Суть моего первого поста, который заминусовали была как раз в том, что визуальные технологии много старше, чем предполагает автор. :)
Из нашего диалога вообще следует парадоксальный вывод: современные ИДЕ постепенно идут в ту сторону, только окольными путями. Уже встроены UML кое где, уже есть контроль переменных и имен, подсветки синтаксиса .. осталось не так уж и много. ;)
(я не минусовал, но считаю, что минусуют более чем заслуженно.)
Ещё раз, спасибо за развернутый ответ, на Хабре не так давно, поэтому любопытно за что минусуют без пояснений. То есть "не читал но осуждаю, или не понял о чем оно было". ;)
Бывает, учту..
Фундаментальная проблема Дракона — в том, что Заказчик не желает писать алгоритм.
может, и желает. Но не может. ибо для этого нужны определенные профессиональные навыки.
так же, как "sql для секретарш", так же, как "СКД (1с) для бухгалтеров" — вроде и сделано "для всех", но вот пользуются "не только лишь все".
поэтому заказчик находит и нанимает профессионала, каковому визуальщина если и нужна, то не как инструмент, а как визуализация. Ну и упомянутый "uml" становится инструментом визуализации и согласования...
Нууу.. Заказчик хочет волшебную кнопку "все готво" и желательно вчера. Но, как раз как инструмент Заказчика и архитектурного проектирования в стиле Document first, кмк, самое оно.
Лично мне в этой части знание и опыт применения ДРАКОН в обучении сильно помогает в работе: проектирование архитектуры кейсов по тому что заказчик часто называет "ТЗ", кмк, даже и не знаю как иначе. Вся "чистая архитектура" тут наглядна.
Визуальное программирование vs DSL