Как визуально выглядит компьютерная программа

Визуальное программирование-это создание компьютерной программы с использованием графических элементов.

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

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

Визуальное программирование и его возможности

Графическое программирование позволяет людям описывать процессы с помощью иллюстраций. Типичный текстовый язык программирования заставляет программиста думать, как компьютер. Визуальный язык программирования позволяет программисту описать процесс в терминах, которые имеют смысл для людей.

Python как сделать красивую программу под ПК за 10 минут?

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

Например, чтобы создать список дел в инструменте визуального программирования, программист рисует поток приложения. Результирующая блок-схема описывает экраны, взаимодействия пользователей и то, что происходит с данными на каждом этапе. Затем инструмент превращает это в программное обеспечение.

Текстовые языки программирования полностью сосредоточены на реализации — это точные шаги, которые компьютер должен предпринять, чтобы создать продукт, который мы хотим предоставить пользователю. Конечно, языки более высокого уровня и современные фреймворки дают нам удобные ярлыки. Но задача разработчика — перевести человеческие потребности в процессы, которые соответствуют ограниченным возможностям компьютера.

Визуального программирование следуют тем же процессам и парадигмам, что и текстовое программирование. Представьте, что вы рисуете класс и его связь с объектами, которые вы создаете, а не печатаете все это в текстовом редакторе. Все это звучит здорово! Но, спросите вы, где все визуальные программисты? Почему мы все еще пишем код вручную?

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

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

Начало 20-го века было временем утопических усилий по продвижению человечества вперед. Бурно развивалось производство и это вызвало необходимость документирования технологических процессов. В результате мы получили схему технологического процесса.

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

В 1949 году пионеры информатики Герман Гольдстайн и Джон фон Нейман стали первыми, кто применил блок-схемы для описания компьютерных программ, работая на компьютере ENIAC. Такой визуальный язык был необходим, когда программирование было вопросом правильной установки тысяч десятипозиционных переключателей кольцевого счетчика.

По мере развития вычислительной техники в последующие годы ученые впервые использовали языки ассемблера. Затем они перешли на языки более высокого уровня, такие как FORTRAN и COBOL, которые задают стандарты для языков, которые мы используем и сегодня. В каком-то смысле каждый новый язык был одним и тем же.

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

Визуальное программирование в современности

Рост мощности компьютерного оборудования позволил программному обеспечению решать все более сложные проблемы. Эта возросшая сложность привела к некоторому изменению роли визуального программирования и текстового программирования. Простую систему управления персоналом или технологическим процессом легко представить визуально.

В 1990-е годы визуальное программирование разделилось на три ветви, каждая из которых занималась определенной проблемной областью:

1. Бизнес-приложениями;
2. Мультимедийными системами и играми;
3. Развитием образования.

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

• Tersus для веб-приложений
• MVPL для робототехники
• LabVIEW для ученых
• SynthMaker для аудио инструментов

Визуальное программирование критикуют за то, что оно делает программы игрушечными. Также количество визуальных элементов, которые могут быть показаны на экране одновременно ограничено. Предел Дойча указывает, что может быть показано примерно 50 элементов.

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

Образовательные среды визуального программирования

Визуальное программирование Scratch или Lego активно используются в системах образования. Проект Lego Mindstorms предлагает визуальный язык программирования, основанный на LabVIEW, для взаимодействия с программируемыми блоками Lego.

Рассмотрим более подробно программируемые блоки Lego EV3. Блоки находятся в нижней части окна среды программирования Lego. Эта группа блоков носит название палитра блоков. Всего есть шесть типов блоков у которых для удобства в верхней части расположена полоса разного цвета:

1. Блоки действия – семь блоков зеленого цвета
2. Блоки управления операторами – пять блоков оранжевого цвета
3. Блоки датчиков – одиннадцать блоков желтого цвета
4. Блоки операций с данными – десять блоков красного цвета
5. Блоки дополнений – десять блоков синего цвета
6. Мои блоки – в этом типе блоков будут располагаться созданные вами блоки темно-зеленого цвета

На начальном этапе изучения Lego EV3 используются в основном блоки действия, управления операторами и блоки датчиков. Остальные типы блоков используются для сложных проектов, для конкурсов и соревнований.

Визуальное программирование — будущее программистов?

Источник: legoteacher.ru

Почему визуальное программирование и D3NE могут быть Вам полезны

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

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

Кадр из сериала «Кремниевая долина»

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

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

Зачем и где применяют визуальное программирование

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

Похожий инструмент от Google под название Blocky

Существует другой вид визуального программирования, более полезный на мой взгляд, это Data-flow programming. Он не такой гибкий как предыдущий и служит некоторой надстройкой для программирования процессов определенной тематики. Его суть состоит в манипуляции данными, передаваемыми между блоками (узлами).

Пример редактора узлов из Blender

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

Редактор узлов в Blender — именно тот случай, когда используется программирование потоков данных для управления рендерингом, создания шейдеров и текстур. Такой подход в 3D моделировании и рендеринге достаточно популярен, так как никому не хочется писать код, а создавать инструкции для нелинейного управления данными необходимо.

Также известный всем в сообществе 3D моделлеров это Substance Designer, который позволяет создавать 3D материалы по принципу, описанному выше.

Редактор для создания материала в Substance Designer

Хотя в официальных источниках упоминания о программировании нету, в нем используется самый настоящий data-flow. Наверное, это такой маркетинговый ход — не говорить о том, что может отпугнуть.

Итак, разобрались в том, почему визуальное программирование используется в 3D моделировании, но как насчет тех сфер деятельности, где без умения писать код не получится сделать достаточно функциональный продукт? Казалось бы, если умеешь писать код, то просто нужно развивать этот навык, но нет — именно в геймдеве одними из первых стали применяться инструменты для программирования без кодинга. С одной стороны, это было выгодно для популяризации геймдева среди тех, кого отпугивает код лишь одним видом, с другой — прогресс не стоит на месте и даже гуру программирования надоело ставить пробелы вместо табов чтение тысяч строк кода и его поддержка, и они решили попробовать новые методики описания логики и процессов.

Многие знают UE4 с его Blueprint’ом. Это уже не просто data-flow, а что-то большее, так как позволяет формировать инструкции, которые будут выполняться не за один проход, а в течении всего жизненного цикла.

Пример вывода строки по событию

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

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

Общие аспекты разработки редакторов узлов

Допустим, однажды вы увидели как делают магию программируют с использованием какого-то редактора с блоками и линиями. К вашему удивлению это оказалось именно тем, что позволит воплотить вашу идею (скажем, какой-то продвинутый генератор диалогов, которые представить в виде обычного графа не получится).

Главное, от чего будет зависеть процесс разработки — платформа и технологии. В последнее время много чего можно сделать прямо в браузере, пусть даже пожертвовав производительностью, что в большинстве случаев никак не отразится на качестве приложения (в ином случае asm.js/wasm в помощь). Одна из особенностей таких приложений — они могут быть встроены в другие нативные приложения. Выбор инструментов и языков программирования должен быть в интересах разработчика, чтобы сделать процесс разработки более комфортным и эффективным и снизить вероятность выстрелить себе в ногу появления проблем.

Определившись с платформой и языком, было бы хорошо использовать готовые решения (в нашем случае речь идет о редакторе узлов), но и здесь не все гладко.
Есть несколько вариантов:

1. вы используете готовое решение, которое вскоре окажется не таким подходящим и удобным, в придачу к этому вам лень не под силу подправлять его под себя
2. написать свою реализацию, заодно изучив как это все работает изнутри и куда прикручивать колеса.
3. использовать готовое решение, которое достаточно гибкое и позволяет без проблем настроить его под себя, не жертвуя при этом выгодными фичами для вашего продукта.

Что такое D3NE

D3 Node editor (D3NE) — это JS библиотека для создания редакторов узлов для решения задач визуального программирования. Библиотека полностью берет на себя работу по отображению и обработке узлов. Использует D3.js и Angular Light

На GitHub Wiki доступен туториал, а также подробное описание всех компонентов и терминологии, используемой в библиотеке (вики на англ. и возможны грамматические ошибки, поэтому буду рад помощи в их исправлении)

Все началось с одного проекта (так он и лежит в draft’ах), в котором появилась идея применить что-то похожее на UE4 Blueprint, только с поправкой на то, что нужен просто data-flow. Среди готовых open source решений на JS не оказалось подходящих: критериями были внешний вид и необходимые возможности (например, разные типы сокетов, чтобы ограничить подключение несовместимых выходов и входов). Если первое еще можно было как-то подправить извне, то добавление второго могло бы вызвать проблемы, тем более если структура и исходный код оставляют желать лучшего.

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

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

Как применить в своем проекте

Для начала нужно выяснить, необходимо ли это вам. Конечно, попробовать для себя кое-что новое никогда не помешает (если это не навредит здоровью 🙂 ), но при решении реальных проблем стоит подумать.

Лучше один раз увидеть, чем… в общем посмотрите примеры:

• Data-flow programming — пример сложения чисел
• События и условное управление данными — примерно так это делается в UE4
• Кастомизация — возможность изменять не только стили, но и структуру узлов и способ соединений
• Allmatter — проект, основанный на этой библиотеке

Пример кастомизации в стиле UE4

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

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

Узлы обычно представляют прямоугольниками (но можно это изменить в пределах вашей фантазии и возможностей CSS и HTML). Они могут иметь входы, выходы и контролы. Входы и выходы представляют сокеты и расположены в левой и правой части узла соответственно (опять таки вы можете их расположить как угодно, используя шаблоны).

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

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

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

Воркер в качестве параметров дает вам входы, выходы и объект с данными узла (не экземпляр, который создается в билдере, а то, что из него достали через toJSON). Входной массив содержит данные, которые пришли на вход из другого узла и массив с выходными данными, в который вы должны положить данные, зависимо от того, что должен делать узел)

Один из основных объектов, который управляет всем вышеперечисленным с целью отображения и взаимодействия с пользователем. Ему передаются идентификатор, компоненты, контекстное меню.

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

Как видим, визуальное программирование хоть и призвано заменить написание кода, но довольно редко используется в настоящий момент. Наверное потому, что многие скептически относятся к идее программирования мышкой. Это отчасти справедливо, так как большинство задач в разработке ПО привычнее будет решить на каком-либо языке программирования, чем использовать недостаточно проверенный инструмент.

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

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

• визуальное программирование
• программирование
• визуализация

• JavaScript
• Программирование
• Разработка игр
• Визуализация данных
• Визуальное программирование

Источник: habr.com

Визуальный программинг: Конструируем приложения с помощью HiAsm

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

Все когда-то начиналось с Ассемблера. Машинный язык мнемонических команд был полностью завязан на архитектуру процессора, под который писалась программа, но при этом стал одним из первых общеиспользуемых языков программирования. Позже появились языки высокого уровня, абстрагирующие программиста от аппаратной части: Basic, Pascal, C и другие.

Гораздо больше времени потребовалось на осмысление, понимание и реализацию объектно-ориентированного подхода (ООП) в программировании, которое позволило еще проще описывать объекты реального мира терминами мира виртуального и породило букет языков следующего поколения, в том числе Delphi и C++. Среды для этих языков впервые стали вводить в обиход понятие «визуальное программирование», которое использовалось исключительно в конструкторах форм и интерфейсов. Наконец, последней волной стало появление сред, позволяющих визуализировать все этапы разработки ПО – от проектирования внешнего вида до реализации программного ядра – LabView, HiAsm, SoftWire и прочие. Как это выглядит? Сейчас разберемся.

Знакомьтесь – HiAsm

HiAsm – среда визуального программирования, программы в которой не пишутся, как это делается в классических языках, а проектируются из кубиков и линий связей между ними. Каждый такой кубик представляет собой элемент, который выполняет какое-то достаточно простое и узкоспециализированное действие (например, копирует файл, проигрывает звук, складывает два числа, качает файл из Internet и т.д. и т.п.).

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

Посмотрим, как выглядит нарисованная таким образом программа классического «Hello world!», которая при нажатии кнопки выводит на экран соответствующее сообщение. Внешний вид схемы, реализующей данный функционал, представлен на рисунке. Собранное приложение состоит из двух элементов: Кнопка (Button) и Сообщение (Message), одной связи между ними (проложенную от события нажатия кнопки к методу показа сообщения) и одного измененного свойства Message (с текстом «Hello world!»). Мы не пишем ни одной строчки кода, но если заглянуть в исходник, то увидим исходник, который сгенерировала HiAsm:

Make(delphi)
Add(MainForm,2953706,21,105)
>
Add(Button,147563,189,105)
Left=180
Top=110
link(onClick,5363509:doMessage,[])
>
Add(Message,5363509,238,105)
Message=»Hello world. »
>

Сгенерированный код написан на языке Object Pascal, но есть и другие варианты. По сути, HiAsm представляет собой не более чем графический векторный редактор. А все его возможности по созданию приложений определяются уставленными пакетами и компиляторами. На текущий момент времени самым мощным из них является пакет Windows, использующий в качестве целевого языка Object Pascal для компиляторов FPC и Delphi. Помимо этого существуют следующие пакеты:

• PocketPC с целевым языком C++ и компилятором MS ARM для платформы Microsoft Windows Mobile;
• WEB – целевой язык PHP с поддержкой JavaScript и HTML;
• QT – целевой язык C++ для платформ Windows, Linux и MacOS;
• VBS – целевой язык Basic платформа Windows и прочие менее развитые.

Также в статусе «just for fun» существует online-версия HiAsm (hion.hiasm.com), с помощью которой можно поучиться составлять схемы, имея под рукой лишь браузер.

Пишем тестер веб-сервера