Про визуальное программирование мы не слишком высокого мнения из-за некоторых проблем с этой методологией. Но этот язык особенный.
Подробно расскажем о языке ДРАКОН — визуальный алгоритмический язык программирования и моделирования, который изначально разрабатывался для космической программы «Буран».
Это русский вклад в Computer Science.
В 1976 году в СССР в обстановке строжайшей секретности началась разработка многоразового транспортного космического корабля Буран в рамках проекта «Буран-Энергия». Это был грандиозный проект. В его создании принимали участие 86 министерств и ведомств и 1286 предприятий СССР (всего около 2,5 миллиона человек).
Свой первый и единственный космический полёт «Буран» совершил 15 ноября 1988 года. Полёт прошёл без экипажа, полностью в автоматическом режиме. В отличие от американского Шаттла, который может совершать посадку только на ручном управлении.
При создании языка ДРАКОН были выдвинуты необычные для программистов и математиков требования гуманитарного характера.
Рассмотрим наглядно необычные идеи, заложенные в язык:
- Предложить средства для описания не только алгоритмов, но и структуры человеческой деятельности в любой отрасли знаний (включая бизнес-процессы);
- Предоставить пользователю языковые средства, которые заставляют человека мыслить продуктивно
- Облегчить межотраслевое и междисциплинарное общение между представителями разных организаций.
- Устранить или уменьшить барьеры взаимного непонимания между работниками различных специальностей и профессий;
- За счёт использования когнитивно-эргономического подхода к проектированию (синтаксиса и семантики) языка добиться улучшения качества программного обеспечения по критерию «понятность алгоритмов и программ».
Получилось ли это и чем все закончилось мы ответим в этом видео. А также затронем основные ограничения визуального программирования.
В 1986 году начальнику лаборатории комплексной разработки вычислительной системы Бурана Владимиру Паронджанову поручили создать универсальный язык, способный заменить три языка, которые до этого использовались при разработке систем Бурана.
Устный язык человечества годиться только для самых простых задач. Как только мы делаем более сложные задачи – мы должны привлекать письменный язык.
Некоторые ученые считают, что письменный язык это простая проекция устного языка, но это не так. Но и письменный язык в виде текста тоже не годиться для сложных задач.
Поэтому добавляется язык математических и иных формул (химических, логических) и графический язык. Графический язык обладает колоссальной мощью.
Как вообще происходит программирование на этом гибридном языке? А гибридном, потому что:
ДРАКОН не является самостоятельным языком программирования. Он работает в паре с текстовым языком, например, с JavaScript, Python или C++. Вместе с текстовым языком, ДРАКОН образует гибридный язык: ДРАКОН-JavaScript, ДРАКОН-Python или ДРАКОН-C++.
Программирование происходит по следующему алгоритму
- Рисуем ДРАКОН-схему.
- Внутрь икон помещаем небольшие кусочки кода на соответствующем языке программирования.
- Программа-транслятор преобразует ДРАКОН-схему в текстовый файл с исходным кодом.
- Этот текстовый файл включается в проект обычным образом.
- Генерацию кода из диаграмм на сегодняшний день поддерживают несколько редакторов. Например — DRAKON Editor.
ДРАКОН — очень легкий язык. Настолько легкий, что разработку многих компьютерных программ для космических ракет на практике ведут не программисты, а инженеры — по принципу «программирование без программистов».
Причина отказа от программистов проста. При решении практических прикладных задач инженеры досконально владеют материалом и прекрасно знают постановку задачи.
В отличие от них программисты не знают «физику процесса» и становятся «лишними людьми», без которых в ряде случаев (хотя и не всегда) вполне можно обойтись.
Сейчас язык используют в основном энтузиасты. Есть люди, которые приспособили его даже для описаний бизнес процессов и разработки решений для 1С, ну и их автоматизации, естественно.
Еще его используют в медицине, там целый пласт международного использования – но это уже не программистское применение.
А теперь пару слов про процесс составления Дракон – Схем выглядит следующим образом.
Из каждой диаграммы создаётся функция.
- Название диаграммы становится названием функции.
- Параметры функции берутся из иконы «Формальные параметры», что расположена справа от названия диаграммы.
- Тело функции генерируется, исходя из структуры диаграммы и содержимого икон.
Я в самом начале сказал, что у меня есть претензии к такому подходу. Возможно, я просто старовер. Но выскажу их. Судить вам.
Есть проблема с контролем версий и отладкой при работе со схемами, а это важно в промышленном программировании.
Почему же визуальное программирование (создание программ из блоков) не побороло простой текст. Он легко воспринимается, мы взглядом видим структуру, слова, иногда не вчитываясь можем воспринимать словосочетания.
Что характерно для программистов — определенные конструкции языка легко различимы на фоне остального программного кода. Они постоянно повторяются и запоминаются, да еще и средства разработки (различные редакторы) подсвечивают блоки. Так может стоит эти блоки изобразить графически? Визуальная информация еще лучше воспринимается человеком. Такие идеи приходили многим еще с 70-х годов двадцатого века.
Единственный язык, напрямую выполняемый ЭВМ — это машинный язык- код. Изначально все программы писались в машинном коде, но сейчас этого практически уже не делается. Вместо этого программисты пишут исходный код на том или ином языке программирования, затем уже он транслируется в машинный код.
Прорыва до сегодняшнего дня не случилось
Для моего коллеги, как-то было открытием узнать, что его любимый терминал в котором он пишет скрипты в Linux — Bash (популярная разновидность командной оболочки UNIX) тоже всего лишь программа. Многослойные пироги из интерфейсов и представлений везде встречают нас в мире компьютеров. Даже текстовые интерфейсы — это всего-лишь слой над машинным кодом.
Визуальное программирование
Манипулирования графическими объектами вместо написания её текста часто представляют как следующий этап развития текстовых языков программирования. Наглядным примером может служить утилита Визуальный Pascal или Microsoft Visual Studio, где редактируются графические объекты и одновременно отображается соответствующий текст программы. Но эти среды и инструменты не дают полного перехода к визуальному программированию. Здесь отдана на откуп только часть с графическими интерфейсами.
Одним из первых инструментов визуального программирования, более известных и дружелюбных, можно считать Scratch. Он предназначен исключительно для образовательных целей, так как представляет собой те же блоки кода, только обернутые в разноцветные пазлы. Практической пользы нет минимум.
Похожий инструмент от Google под название Blocky
Основная проблема в том, что часто в крупных бизнес проектах пишется невероятно сложная бизнес логика, которая посредством функций легко разделяется. Текст плотнее.
И пока представление в виде картинки увеличивает площадь на единицу цикломатической сложности, ничего хорошего не получится.
Схемы просты, пока они маленькие.
Я сам проектировал некоторые штуки в виде майндмапов, и они пригодны к работе только пока маленькие. Читаемость больших схем ужасна.
К слову сказать, Дракон-Схемы упорядочены, т.е. структурированы по особому закону, потому отличаются от обычных майндмапов. Но продолжим.
Текстовый вид удобен тем, что для него выработаны некоторые приемы декомпозиции. Ну например, можно легко назвать две парадигмы — ООП и функциональное программирование. И мы знаем, на какие части надо разбивать, и как их компоновать друг с другом (шаблоны проектирования, или монады).
В случае диаграмм ничего из этого нет. Но есть свои парадигмы, опять же ограничения именно в Драконе.
Стоит еще немного напомнить, что структурное программирование, ООП — это именно ограничения, которые мы добровольно приняли, чтобы иметь возможность разбираться в своих программах.
В некоторых областях графическое программирование может применяться, а то и быть самым удобным инструментом (например, в движках для разработки игр).
При разработке Бурана проблема разработки и отработки программного обеспечения считалась одной из наиболее сложных. Первоначально предполагалось, что для решения задачи потребуется несколько тысяч программистов.
Следует учесть, что наши программисты привыкли писать программы на ассемблере, так как объем памяти бортового компьютера «Бисер-4» в тот период был очень ограниченным.
Но все конечно же не так плохо. Действительно частично подходы графического программирования проникли в «кровавый интерпрайз».
Геймдев в след за 3D спецами активно использует подход графического программирования. И там он кристально чистый.
Это Dataflow programming — я имею в виду Blueprint от Unreal Engine.
При запуске игры все Blueprint коды транслируются на язык C++. У профессионального программиста разница между скриптом на Blueprint и на С++ может быть почти незаметна. Здесь также играет роль упорядоченности Blueprint схем – такой же упорядоченности как и в Дракон-схемах. Важно, чтобы графический язык был упорядочен и однозначен. Иначе получится клубок ужаса.
Вот например, в Blueprint есть узлы для отправки событий. Подключенные к ним узлы выполняются только в тот момент, когда срабатывает событие. Получается очень удобно, не нужно оперировать какими-то объектами и методами.
Но в тоже время Blueprint — язык объектно-ориентированный, поэтому поддерживает все принципы ООП: абстракция, инкапсуляция, наследование и полиморфизм. Короче, сочетание классики и еще большей классики — смотрите на возраст подхода Dataflow programming.
В мае мы публиковали статью на платформе Яндекс Дзен «Почему Визуальное Программирование не смогло» и получили вот такие комментарии:
Для меня весомым аргументом является Verilog. Это язык описания цифровых устройств. Сейчас любой процессор (тот же Core i7) — это большой набор текстов на Verilog (ну или на VHDL — другом языке). Уже данные текстовки «компилируются» в схему, которая разводится на кристалле. А вся соль в том, что проектирование системы на кристалле — это изначально графический процесс, который был заменён на тот же текст (ибо текст удобнее)
АНО Систематика, в LabView вполне можно использовать ООП, создав при этом отдельный ВП, по принципу программирования не рекомендуется делать больших схем, все сводится в блоки и реализуется между ними соответствующая связь, которая визуально более понятно чем текстом. Согласен с тем что не все можно запрограммировать по простому но не сложные и небольшие проекты вполне.
Использование визивиг программирования требует очень больших ресурсов системы так как блоки написаны довольно коряво на низком уровне. Я люблю Labview где можно сделать хорошую программу выполняющую определенные функции по делу. Конечно же не буду строить на ней бизнес систему. Этим занимается другой человек. Все люди имеют свои таланты. Кто-то работает в электронике при этом программированием забивать голову не хочет. Не все то золото что блестит. Не все коту масленица. Не все йогурты одинаково полезны.
По итогу я скажу так – Подход ДРАКОНа доказал свою состоятельность точно, Буран то полетел и сел. Так что вопросов нет. Но как и любая технология, должна применяться по назначению.
Блок-схемы в Драконе имеют определенную структуру и порядок, а соотвественно единообразны. Применяя такие ограничения мы можем использовать визуальное программирование.
Язык жив, язык выразителен, силен и интересен, он самобытен благодаря особенным правилам, которых нет в других графических языках.
Источник 1 — https://youtu.be/Q7bEWK8FYsc
Источник 2 — https://zen.yandex.ru/media/anosistema/pochemu-vizualnoe-programmirovanie-ne-smoglo-5ceb6ebd44f2e000b49f6cad
Источник 3 — https://youtu.be/VcKMH2JScyY
Источник 4 — https://youtu.be/Bj6l0W2BBnM
Источник 5 — https://youtu.be/j7jMwuEOGqw
Источник 6 — https://old.computerra.ru/readitorial/418507/
Источник 7 — https://drakon.su/
Источник 8 — https://habr.com/ru/post/345320/
Отправить ответ