Мови візуального програмування

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

Чому для розробників не існує основних, візуальних мов загального призначення? Які переваги та недоліки візуального програмування?

Взагалі існує компроміс у дизайні мови програмування між простотою використання та виразністю (потужністю). Написати просту програму "Привіт, світ" мовою для початківців, наприклад, Scratch або App Inventor, як правило, простіше, ніж писати її загальноприйнятою мовою програмування, наприклад Java або C ++, де у вас може бути вибір декількох потоків вихід на різні набори символів, можливість зміни синтаксису, динамічних типів тощо.

Під час створення App Inventor (до складу якої я входив) наша філософія дизайну полягала в тому, щоб програмування було простим для початківців. Тривіальний приклад базував наші індекси масиву на 1, а не на 0, хоча це робить обчислення, які, ймовірно, будуть виконувати передові програмісти, трохи складнішими.

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

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

Справедливість не може бути надана цій темі (принаймні мені) в кількох абзацах, але деякі основні причини:

1. Блокові мови, як правило, розроблені для початківців, тому не такі потужні за дизайном.
2. There is no nice visual way of expressing some complex concepts, such as type systems, that you find in general-purpose programming languages.
3. Using blocks is unwieldy for complex programs.

Why are there no mainstream, general-purpose visual languages for developers? What are the advantages and disadvantages of visual programming?

Visual languages tend to broken it three broad categories:

1. Tools non-programmers to perform basic automation tasks. Think Automator on the Mac.
2. Learning environments where it's not practical to have lots of typing, or where the structure of the program showing logical flow is important. Think Scratch, Alice, etc.
3. The problem being addressed is a data-flow problem, and the solution to the problem is well modeled by some sort of data flows between self-contained boxes that mimic the physical world. LabView and Ableton both come to mind.

The advantage to visual programming is that you get a high-level overview of system structure. This leads to the immediate problem that when you get detailed, your spaghetti code really looks like spaghetti. A common component of visual languages is some sort of code block or configuration component for the visual element. The problem is that the programmer needs to make sense of disconnected code blocks that may be interlinked in strange ways.

While there is nothing wrong with visual programming, it may be the case that it's simply not a good approach for most tasks.

There have been numerous visual programming languages, as the following two bibliographies will show: vlib.org and oregonstate.edu.

IMHO they have failed to gain traction, because whilst they are good for toy examples, they fail to manage the multiple levels of abstraction, representation and granularity that large projects require. You would need to look at a system like AutoDesk Revit (a building information management system used by architects and engineers) to see how complex managing visual information can become.

Rather than looking at general purpose programming, visual programming is most likely to succeed as a configuration tool in specialised domains.

Text is visual.

We use all kinds of visual cues in our code. Every use of whitespace (indents, new lines, blank lines, intraline spacing) is directed towards providing visual cues for the functionality of the code. We use all kinds of different syntax to provide visual information on what code is doing. Our editors color our code to make it stand out.

Mathematics is textual. There is all kinds of notation, but in the end it comes down to basically text. They have been doing for hundreds of years.

My point: the textual representation of code is making use of the visual abilities that humans have. We can probably make better use of it, but not by abandoning text.

[For the PDF version of this reply, the figures or diagrams are interactive and dynamic.]

Net Elements and Annotations: A General-Purpose Visual Programming Language

I use graphics to organize JavaScript™ programs that use the Acrobat®/JavaScript API. Each graphic object represents a Petri Net element (place, transition, input or output) or represents more than one Petri Net element. Each graphic object is actually an annotation of the corresponding net element. However, if every graphic object maps to one and only one net element it may be used to generate the net element. And if a graphic object maps to more than one net element and the mapping is well-defined then it may also be used to generate the net elements. Standard Petri Net elements are represented by certain types of graphics: a circle is a place, a square or rectangle or line is a transition, an arrow from a circle to a square is an input and an arrow from a square to a circle is an output. Furthermore, a net element that is represented by a standard graphics has a set of de-facto standard annotations associated with it.

[The types of annotations in a "Standard Petri Net" are found in the PDF version of this reply.]

Carl Adam Petri described most of these ideas (including the types of annotations in a "Standard Petri Net" in his doctoral dissertation (Petri, 1966). He also applied the net elements and annotations to the description of several logic circuits, such as Figure 6.

Benefits and Challenges

A visual programing language may help a computer programmer develop computer programs (Menzies, 2002).

I have at least three reasons why I find net elements and annotations useful (advantages?).

Firs reason. The process logic can be created one element at a time. This means that a net can be extended by adding elements to the existing net (Petri, 1966). For example, a model of a controller can be divided into internal and external components. The internal component regulates the system. The external component interfaces with the environment by accepting input from the environment. Figure 1 is a Petri Net model of the internal component. It is possible to add a Petri Net model of the external component to the Petri Net model of the internal component by adding the appropriate places and transition (Figure 2).

Figure 1 A Petri Net Model of an Internal Component of a Controller (Halloway, Krogh and Giua, 1997)

Figure 2 A Petri Net Model of an Internal and External Components of a Controller (Halloway, Krogh and Giua, 1997)

Second reason. The codes associated with each net element can come from more than one “programming language” (Petri, 1973). They can come from a computer language such as JavaScript, COBOL, ADA and an assembly language. They can come from a Mathematical language such as algebraic symbols. They can come from prose encoded in English, German, French, Greek, Tagalog, Chinese, etc. Thus it may be used as a basis for communication and collaboration throughout the software or system development life cycle; and among different users, developers and stakeholders (Petri, 1973).

Third reason. It is possible to focus on certain graphics objects in the net and to write out the code or logic annotations for the related graphics objects. Consider a Petri Net model of a card game in Figure 3. If the arrow for the input P7  T4 is a standard graphics for an input in a Place/Transition Net and if m_7 is the mark for the place P7 then the logic annotation for updating the mark of the input place is m_7=m_7-1. If s_9^- is the status of the input then the logic annotation for updating the status of the input is s_9^-=((m_7<1) ?false:true).

Figure 3 A Petri Net model of a card game

I have at least three reason why I find the application of Petri Nets challenging (disadvantages?)

Якщо графічних об’єктів занадто багато, то створити чи прочитати мережу буде важко. Труднощі можна зменшити, взявши підмножину графіки та представити їх за допомогою одного, двох або трьох графічних символів (Noe, 1973; Petri, 1966). Наприклад, якщо вважається, що модель Петрі Net в картковій грі на малюнку 3 має занадто багато графічних об’єктів на діаграмі, можливо, комбінувати частину графіки та зберігати достатню кількість інформації для відображення діаграми в комп'ютерну програму. Розглянемо на малюнку 4 модель Петрі Net тієї ж гри, знайденої на рисунку 3 із графікою високого рівня (Chionglo, 2016a).

Малюнок 4 Сітка Петрі Модель карткової гри за допомогою графіки високого рівня (Chionglo, 2016a)

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

Малюнок 5 Сітчаста модель Петрі контролера з високим рівнем графіки для зовнішніх компонентів

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

Друга причина. Навіть із стандартною графікою може бути складним малювати та розміщувати графіку, особливо якщо очікує, що остаточна схема буде зручною для користувачів чи читача. Деякі рішення для створення зручної для користувача або читача діаграми включають: правильне розташування графічних об’єктів, відповідні розміри полотна та форми, кривизна стрілок, тип головок стрілок, розмір і шрифт тексту, та вибір кольорів для графіки та тексту.

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

Малюнок 6 Місце чи перехідна мережа з анотаціями - на основі рисунка 31, сторінка 78 англійського перекладу дисертації Петрі (1966)

Одним із способів пом'якшити цю проблему було б визначити типи анотацій, які використовуються в моделі, та визначити графічні об’єкти, які включають примітки цих типів (Petri, 1966). Таким чином, коли діаграма Петрі Net складається з графічних об'єктів із визначень, інтерпретація цих об'єктів повинна включати «невидимі» анотації. Рисунок 7 слід інтерпретувати як Стандартну мережу Петрі (для означень див. Анотації Стандартної мережі Петрі); отже, логічну анотацію можна випустити з діаграми.

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

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

Список літератури

Chionglo, JF (2016a). Відповідь на тему "Як спроектувати потік стану для гри на реакцію / скорочення флешкарту?" На сторінці переповнення стека. Доступно за адресою https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow .

Chionglo, JF (2016b). Перегляд двох форм мережі Петрі. Доступно за адресою http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .

Chionglo, JF (2015). Зменшення кількості графічних елементів з елементами в діаграмі Петрі Net за допомогою графіки високого рівня. Доступний за адресою http://www.aespen.ca/AEnswers/WjTpY1429533268 .

Chionglo, JF (2014). Чисті елементи та примітки для комп'ютерного програмування: обчислення та взаємодії в PDF. Доступно за посиланням https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

Halloway, LE; Krogh, BH та Giua, A. (1997). Огляд методів Петрі Net для керованих дискретних систем подій [електронна версія]. Дискретні динамічні системи подій: теорія та програми, Вип. 7. Бостон: Kluwer Academic Publishers, С. 151 - 190.

Мензіс, Т. (2002). Питання оцінювання мов візуального програмування. У СК Чанг (Ред). Посібник з інженерії програмного забезпечення та інженерії знань, Vol. 2 Нові технології. Всесвітнє наукове видавниче співробітництво. Pte. ТОВ, С. 93 - 101.

Ное, Дж. Д. і Натт, Дж. Дж. (1973). “Макросистемні електронні мережі для представлення паралельних систем”, IEEE Transaction on Computers, vol. С-22, № 8, серпень 1973, стор 718 - 727.

Петрі, Каліфорнія (1973). Поняття чистої теорії. В Математичні основи інформатики: зб. симпозіуму та літньої школи, Високі Татри, 3 - 8 вересня 1973, стор. 137 - 146. Математика. Інст. словацького акад. наук, 1973.

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

Johne Percival Hackworth:

While there is nothing wrong with visual programming, it may be the case that it's simply not a good approach for most tasks.

Perhaps, the visual programming languages to date have just been too immature? The notion that advanced visualizations cannot be applied to software artifacts and that they are left completely up to the 'imagination' of each developer to roll their own might be a false assumption. Raising the level of abstraction in a uniform and automated way seems obvious, so as long as the ability to perform low-level abstractions and high execution performance is not sacrificed. This could ultimately lead to domain expert 'programming,' not much different than the way that spreadsheets automated the task of COBOL programmers to manipulate numbers. The primary difference here is replacing numbers with the manipulation of 'general systems.'

You can look at Programming Without Coding Technology (PWCT)

PWCT is a general purpose visual programming language that enables the development of systems and applications by generating interactive steps instead of writing code.

Here is a good place to start and is open source.

a tricky question. visual or flow-based programming has indeed become more used but it is not widely used compared with all programming languages. significant factors are maintenance and standardization. computer code can be printed on pages. it is not always so clear how to print a visual program.

in contrast to the current top answer I would argue there is definitely no inherent theoretical limitation on visual programming power vs textual languages. in fact visual programming may be seen as easier to maintain someday based on faster human conceptualization of the many layers of abstraction. so there seems to be an unmistakable element of social/cultural inertia/conservatism in its uptake.

the visual editors are probably much more complex in their code, and this is formidable considering that even just text based IDEs can be very complex eg Eclipse, note there are visual-programming oriented plugins into some IDEs such as eciplse eg for GUI building. visual programming for GUI building is fairly widespread now.

it appears to me that visual programming use is increasing in select areas and that long from now it may become more common.

lets not forget that visual programming is inherent to EE chip design for decades where it is not an abstraction and (sub)systems are laid out in 2d designs exactly as intended.

the Lego mindstorms kit, now widespread & over a decade old, has always had development software based on visual programming, now streamlined significantly over many versions.

here is an interesting recent article analyzing the history and prospects and suggesting it may become more common for web-based programming. dynamically laying out controls/widgets on a page is a variant of visual-based programming.

another key/emerging area where it is in widespread use in many tools is BPM, business process modelling.

• How An Arcane Coding Method From 1970s Banking Software Could Save The Sanity Of Web Developers Everywhere (Fast Company)

• BPM, Business process modeling wikipedia

I guess the reason why these solutions are not so popular, because in most cases they can be un-manageable and become a mess.

Almost all the visual programming tools available out there today are part of larger applications and used for a specific purpose (ex: Blueprint in UE4).

Anyway a new one I came across recently for general programming is Korduene which is really not quite general purpose, as it is more for creating windows applications.

I think @Raphael and others are wrong when they say a program is text. It isn't. It's many things. It's telling the computer what to do, or how to do it. (imperactive, declarative programming) The association of programming with text editing is historic and counterintuitive dogma. Which was created by the limited textual inputs/outputs of early computers. People are not text parsers!

While I think that people are right that a fully visual language (where you do anything visually, by connecting elements via mouse and such) is impractical a for a general purpose language, I think all current languages could be and should be moved to an intermediate level. Where language elements have a visual representation, which is saved in a binary language file. The programmer wouldn't type text like crazy, or live under the spell of lines and indentation.

But inserts elements via the most productive combination of hotkeys/commands/UI elements. And only types strings and other data and identifiers. This would make syntax errors impossible and make languages with safety and correctness in mind (eg:ADA) way more productive. And would also make others safer and less buggy, by making whole classes of common errors impossible. (Such as the ones ADA prevents by being cumbersome)

To some degree things were heading this way. By automatic indentation and syntax coloring. Sadly no-one realized (or cared enough) that it's the core concept of the "human text parser" is what's wrong. The emacs vs vim arguments are funny because both are wrong. They are "solutions" to an artificially created problem.