Языки визуального программирования

Большинство из нас изучали программирование с использованием «текстовых» языков программирования, таких как Basic, C / C ++ и Java. Я считаю, что для людей более естественно и эффективно мыслить визуально. Визуальное программирование позволяет разработчикам писать программы, манипулируя графическими элементами. Я предполагаю, что использование визуального программирования должно улучшить качество кода и уменьшить количество ошибок в программировании. Мне известны несколько визуальных языков, таких как App Inventor , Scratch и LabView .

Почему нет общепринятых визуальных языков общего назначения для разработчиков? Каковы преимущества и недостатки визуального программирования?

В общем, в дизайне языка программирования существует компромисс между простотой использования и выразительностью (мощью). Написание простой программы «Hello, world» на языке начинающего, например Scratch или App Inventor, обычно проще, чем на языке программирования общего назначения, таком как Java или C ++, где вы можете выбрать несколько потоков для вывод на различные наборы символов, возможность изменения синтаксиса, динамических типов и т. д.

Во время создания App Inventor (частью которой я был) наша философия дизайна заключалась в том, чтобы сделать программирование простым для начинающего. Тривиальный пример - основание индексов нашего массива на 1, а не на 0, хотя это делает вычисления, вероятно, выполненными опытными программистами несколько более сложными.

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

Когда пользователи начинают создавать более сложные программы на языке блоков, они обнаруживают, что перетаскивание блоков происходит медленнее, чем при наборе текста. Вы бы предпочли напечатать "a * x ^ 2 + b * x + c" или создать его с блоками?

Правосудие не может быть дано этой теме (по крайней мере, мной) в нескольких параграфах, но некоторые из основных причин:

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

Почему нет общепринятых визуальных языков общего назначения для разработчиков? Каковы преимущества и недостатки визуального программирования?

Визуальные языки имеют тенденцию разбивать его на три широкие категории:

1. Инструменты непрограммисты для выполнения основных задач автоматизации. Подумайте, Automator на Mac.
2. Среды обучения, где нецелесообразно много печатать, или где важна структура программы, показывающая логический поток. Подумайте, Царапина, Алиса и т. Д.
3. Решаемая проблема - это проблема потока данных, и решение этой проблемы хорошо моделируется какими-то потоками данных между автономными блоками, которые имитируют физический мир. LabView и Ableton оба приходят на ум.

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

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

Было много визуальных языков программирования, как показывают две следующие библиографии: vlib.org и oregonstate.edu .

ИМХО, им не удалось набрать обороты, потому что, хотя они хороши для игрушечных примеров, они не справляются с несколькими уровнями абстракции, представления и детализации, которые требуются крупным проектам. Вам нужно было бы взглянуть на такую ​​систему, как AutoDesk Revit (система управления информацией здания, используемая архитекторами и инженерами), чтобы понять, насколько сложным может стать управление визуальной информацией.

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

Текст является визуальным.

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

Математика - это текст. Есть все виды обозначений, но в итоге все сводится к тексту. Они делают в течение сотен лет.

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

[Для PDF-версии этого ответа рисунки или диаграммы являются интерактивными и динамичными.]

Сетевые элементы и аннотации: универсальный язык визуального программирования

Я использую графику для организации программ JavaScript ™, использующих API Acrobat® / JavaScript. Каждый графический объект представляет элемент сети Петри (место, переход, ввод или вывод) или представляет более одного элемента сети Петри. Каждый графический объект на самом деле является аннотацией соответствующего сетевого элемента. Однако, если каждый графический объект отображается на один и только один сетевой элемент, он может использоваться для создания сетевого элемента. И если графический объект отображается более чем на один сетевой элемент, и отображение четко определено, то его также можно использовать для создания сетевых элементов. Стандартные элементы сети Петри представлены определенными типами графики: круг - это место, квадрат или прямоугольник или линия - это переход, стрелка из круга в квадрат - это ввод, а стрелка из квадрата в круг - это выход. Более того,

[Типы аннотаций в «Стандартной сети Петри» можно найти в PDF-версии этого ответа.]

Карл Адам Петри описал большинство этих идей (включая типы аннотаций в «Стандартной сети Петри» в своей докторской диссертации (Петри, 1966). Он также применил элементы сети и аннотации для описания нескольких логических схем, таких как рисунок 6.

Преимущества и проблемы

Визуальный язык программирования может помочь программисту разрабатывать компьютерные программы (Menzies, 2002).

У меня есть как минимум три причины, почему я считаю полезными сетевые элементы и аннотации (преимущества?).

Первая причина. Логика процесса может быть создана по одному элементу за раз. Это означает, что сеть может быть расширена путем добавления элементов в существующую сеть (Петри, 1966). Например, модель контроллера может быть разделена на внутренние и внешние компоненты. Внутренний компонент регулирует систему. Внешний компонент взаимодействует со средой, принимая входные данные из среды. Рисунок 1 - модель внутреннего компонента Петри Нет. Можно добавить модель внешнего компонента сети Петри к модели внутреннего компонента сети Петри, добавив соответствующие места и переход (рис. 2).

Рисунок 1. Модель сети Петри внутреннего компонента контроллера (Halloway, Krogh and Giua, 1997)

Рисунок 2. Модель сети Петри внутренних и внешних компонентов контроллера (Halloway, Krogh and Giua, 1997)

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

Третья причина. Можно сфокусироваться на определенных графических объектах в сети и выписать код или логические аннотации для связанных графических объектов. Рассмотрим модель сети Петри для карточной игры на рисунке 3. Если стрелка для входа P7  T4 представляет собой стандартную графику для входа в Place / Transition Net и если m_7 - метка для места P7, то логическая аннотация для обновление отметки места ввода - это m_7 = m_7-1. Если s_9 ^ - это состояние входа, то логическая аннотация для обновления состояния входа будет s_9 ^ - = ((m_7 <1)? False: true).

Рисунок 3. Модель карточной игры Петри Нет.

У меня есть по крайней мере три причины, почему я считаю применение сетей Петри сложным (недостатки?)

Если графических объектов слишком много, будет трудно создать или прочитать сеть. Сложность может быть уменьшена, если взять подмножество графики и представить их, используя один, два или три графических символа (Noe, 1973; Petri, 1966). Например, если модель сетевой карты Петри в карточной игре на рис. 3 имеет слишком много графических объектов на диаграмме, можно объединить некоторые графические объекты и при этом сохранить достаточно информации, чтобы отобразить диаграмму в компьютерной программе. Рассмотрим рисунок 4, модель Petri Net той же игры, что и на рисунке 3, с графикой высокого уровня (Chionglo, 2016a).

Рисунок 4. Модель сети Петри для карточной игры с использованием графики высокого уровня (Chionglo, 2016a)

В другом примере внешние компоненты контроллера на рисунке 2 могут быть объединены для создания более краткого графического представления, как показано на рисунке 5.

Рисунок 5. Модель контроллера Петри с высокоуровневой графикой для внешних компонентов.

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

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

Третья причина. Аннотации сетевых элементов легко создавать упорядоченным образом, поскольку каждая аннотация прямо или косвенно связана с сетевым элементом. Однако отображение каждой аннотации вместе с графикой каждого элемента сети может быть не очень хорошей идеей, поскольку на диаграмме может быть слишком много информации. Например, рассмотрим диаграмму модели Петри Сети логической схемы, которая включает ссылки на все свойства и логические аннотации (рисунок 6). [Первоначальная модель включала в себя условие проверки состояния для каждого выхода (рисунок 31 на стр. 78 (Петри, 1966)); условие теста здесь опущено, потому что оно эквивалентно исходной модели для данной начальной маркировки. Таким образом, каждый вывод имеет одну логическую аннотацию для вычисления отметки места вывода.]

Рисунок 6 Место / Сеть переходов с аннотациями - основано на рисунке 31 на стр. 78 английского перевода диссертации Петри (1966)

Одним из способов смягчения этой проблемы может быть определение типов аннотаций, используемых в модели, и определение графических объектов, которые включают аннотации этих типов (Petri, 1966). Таким образом, когда диаграмма сети Петри состоит из графических объектов из определений, интерпретация этих объектов должна включать «невидимые» аннотации. Рисунок 7 следует интерпретировать как стандартную сеть Петри (определения см. В примечаниях к стандартной сети Петри); следовательно, логическая аннотация может быть опущена на диаграмме.

Рисунок 7 Место / Сеть перехода - на основе рисунка 31 стр. 78 английского перевода диссертации Петри (1966)

Другим способом смягчения этой проблемы было бы использование представлений формы аннотаций для дополнения или дополнения диаграммы (диаграмм) (Chionglo, 2016b; 2014). Представления могут быть далее разделены на меньшие представления, и каждый вид может быть отображен и скрыт.

Ссылки

Чионгло, JF (2016a). Ответ на вопрос «Как спроектировать поток состояний для игры с карточкой реагирования / редукса?» В Stack Overflow. Доступно по адресу https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow .

Чионгло, JF (2016b). Два вида формы сети Петри. Доступно по адресу: http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .

Чионгло, JF (2015). Сокращение количества графических элементов в диаграмме Петри с использованием высокоуровневой графики. Доступно по адресу http://www.aespen.ca/AEnswers/WjTpY1429533268 .

Чионгло, JF (2014). Сетевые элементы и аннотации для компьютерного программирования: вычисления и взаимодействия в PDF. Доступно по адресу https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

Halloway, LE; Крог Б.Х. и Джуа А. (1997). Обзор методов Петри Нет для управляемых систем дискретных событий [электронная версия]. Динамические системы дискретных событий: теория и приложения. 7. Бостон: Kluwer Academic Publishers, стр. 151 - 190.

Мензис, Т. (2002). Вопросы оценки для визуальных языков программирования. В СК Чанг (ред.). Справочник по программной инженерии и инженерии знаний, вып. 2 Новые технологии. Всемирная научная издательская компания Рядовой ООО, стр. 93 - 101.

Noe, JD и Nutt, GJ (1973). «Макро-сети для представления параллельных систем», IEEE Transactions on Computers, вып. С-22, № 8, август 1973 г., стр. 718 - 727.

Петри, Калифорния (1973). Концепции Теории Сети. В математических основах информатики: Учеб. Симпозиума и Летней школы, Высокие Татры, 3–8 сентября 1973 г., стр. 137–146. Матем. Текущий месяц Словацкой акад. наук, 1973.

Петри, Калифорния (1966). Связь с Automota [пер. CF Грин младший]. Дополнение I к Техническому отчету RADC-TR-65-377 (Том I). База ВВС Griffiss, Нью-Йорк: Римский центр развития авиации, Научно-технический отдел, Командование ВВС, База ВВС Griffiss. Получено 31 августа 2011 г. с сайта http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf .

Джон Персиваль Хакворт :

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

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

Вы можете посмотреть на Программирование без технологии кодирования (PWCT)

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

Вот хорошее место для начала и с открытым исходным кодом .

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

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

визуальные редакторы, вероятно, намного сложнее в своем коде, и это огромно, учитывая, что даже простые текстовые IDE могут быть очень сложными, например, Eclipse , обратите внимание, что в некоторых IDE есть плагины, ориентированные на визуальное программирование, такие как eciplse, например, для построения GUI. Визуальное программирование для построения GUI в настоящее время довольно широко распространено.

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

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

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

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

другая ключевая / появляющаяся область, где это широко используется во многих инструментах, является BPM, моделированием бизнес-процессов.

• Как метод тайного кодирования 1970-х годов Банковское программное обеспечение может спасти здравомыслие веб-разработчиков везде (Fast Company)

• BPM, Википедия по моделированию бизнес-процессов

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

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

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

Я думаю, что @Raphael и другие не правы, когда говорят, что программа - это текст. Это не так. Это много вещей. Он говорит компьютеру, что делать или как это сделать. (императивное, декларативное программирование) Ассоциация программирования с редактированием текста является исторической и нелогичной догмой. Который был создан ограниченным текстовым вводом / выводом ранних компьютеров. Люди не парсеры текста!

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

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

В некоторой степени дела шли так. Автоматическим отступом и синтаксической раскраской. К сожалению, никто не осознал (или достаточно заботился), что это основная концепция «синтаксического анализатора человеческого текста» - вот что не так. Аргументы emacs vs vim забавны, потому что оба ошибаются. Они являются «решениями» искусственно созданной проблемы.