<p>I'm an advocate for limited use of visual programming.  First, for elementary and middle school kids, languages like Scratch (or variations, such as is used by Lego robotics) seem to work well.</p>
<p>I have no quantitative data, but I have taught it myself to middle school students, and I speak to a LOT of computer science teachers during the course of my duties, so I have some comfort in the assertion that it helps at these lower levels.</p>
<p>Second, there is a reason that devices like FSMs are traditionally diagram-based: they are extremely hard to flow when provided as text.  So areas that traditionally use FSMs, such as animation controllers in Unity, naturally wind up in the visual programming sphere, sometimes augmented just a bit with written programming.</p>
<p>Finally, there are other environments where visual programming has entered the professional sphere, such as Blueprints in Unreal.  They provide limited functionality, but the functionality they provide is a very useful subset, and (take this next with a grain of salt, I have used Unity but never Unreal) allow game designers to do more substantial work without having to ping the developers constantly.</p>
<p>It's hard for me to imagine that we, as highly visual AND highly verbal creatures, would uniformly find that either written programming or visual programming is always a better approach.  We are excellent and processing information in both spheres, with somewhat different strengths in each.  I would actually expect that, given the ideal circumstances, we would most naturally gravitate towards a combination of the two, such as the two major game engines have done.</p>

CC BY-SA 4.0
2022-12-27T10:19:34.660Z
Your points chime with my preconceptions. Diagrams are useful for teaching beginners (not for industrial use), and they are useful to experts in limited cases (like FSMs) that involve a lot of "wiring" and for which there is no good textual alternative known which is as expressive as a diagram.
Steve
CC BY-SA 4.0
2022-12-27T03:12:29.797Z
2022-12-28T04:51:51.800Z
2022-12-28T04:51:51.800Z
Ben I.
<p>Christopher Alexander (the [building] architect and author of the first pattern language book), has stated that words are much better than diagrams when expressing what is wanted in a design. Diagrams always accidentally specify arbitrary things. E.g it is impossible to show a straight line without giving its length. But with words we can say “straight line”. With the diagram we can draw the line, but have to add the words “not to scale”. The words alone are simpler.</p>
<p>Visual programming can however be useful as a way to teach programming. See <a href="https://scratch.mit.edu/" rel="nofollow noreferrer">Scratch from MIT</a> for young kids, <a href="https://snap.berkeley.edu/" rel="nofollow noreferrer">Snap from Berkeley</a>, or many of their derivatives.</p>

CC BY-SA 4.0
2022-12-27T21:00:03.823Z
2022-12-27T21:06:58.373Z
2022-12-27T21:06:58.373Z
ctrl-alt-delor
<p>State diagrams equipped with an animation facility are great tools for communicating temporal behaviour. David Harel introduced <a href="https://en.wikipedia.org//wiki/State_diagram#Harel_statechart" rel="nofollow noreferrer">StateCharts</a> to add <em>hierarchy</em> and <em>concurrency</em> to overcome the inherent limitation in plain state diagrams - they did not scale well. Back in the day an expensive tool was developed that would make the would-be developer create the diagrams as if in a drawing program. That was a failure. Moreover, the original StateCharts had some semantic issues (leading to 95+ published papers on their semantics), nowadays resolved in, e.g., <a href="https://rtsys.informatik.uni-kiel.de/%7Ebiblio/downloads/papers/pldi14.pdf" rel="nofollow noreferrer">SCCharts</a> for which a family of IDEs is <a href="https://rtsys.informatik.uni-kiel.de/confluence/display/KIELER/Overview" rel="nofollow noreferrer">available</a>. What these newer versions have in common is that the pretty diagrams are <em>derived by the tool</em> from the textual representation, i.e., good old-fashioned textual code.</p>
<p><strong>tl;dr</strong>
A classical instance of visual programming has been retired in favour of textual programming augmented with powerful visualisation.</p>

CC BY-SA 4.0
2023-02-08T09:21:39.217Z
2023-02-08T09:21:39.217Z
Kai
<p>Probably the closest modern thing to what you want is UML (Unified Modeling Language). Lots of object oriented design gets expressed in formal or informal UML and there are a lot of tools for creating them. A google search for &quot;object oriented diagramming&quot; will turn up several options.</p>
<p>Flow charts went out of vogue a long time ago, along with common (all?) use of goto statements. The problem with both is that there are too many degrees of freedom with them, leading to a tendency toward short term solutions (quick &amp; dirty) where long term software reliability and maintainability is required.</p>
<p>See <a href="https://en.wikipedia.org/wiki/Goto#Criticism" rel="nofollow noreferrer">wikipedia for goto criticism</a>. David Gries (Cornell prof and important author) always referred to flow charts as &quot;flaw charts&quot;.</p>
<p>It is too easy, with the old tools, to put bugs in and too hard to get them out.</p>
<p>I've built some pretty sophisticated stuff with OO (Java, Python, Ruby) but very simplified UML was always enough. Just enough to show the relationships between important modules.</p>
<p>A programming environment that integrates Java programming with simplified UML is <a href="https://bluej.org" rel="nofollow noreferrer">bluej</a>. The site also includes many programming projects for beginners.</p>

CC BY-SA 4.0
2022-12-27T09:16:26.720Z
I appreciate the answer, but I was primarily asking whether educators find these visual schemes to be *effective*, either as a complete alternative to written code, or as something where the design is done visually and then more or less mechanically translated into code.
Steve
CC BY-SA 4.0
2022-12-27T21:06:29.250Z
UML has some good bits, but the U is a lie. It is not unified, it is a pile of diagram standards. Some useful, some just in there because of who was on the comity. There are other systems BON is more unified. There are also things that UML misses, such as pipeline diagrams, layer diagrams, …, etc, etc.
ctrl-alt-delor
CC BY-SA 4.0
2022-12-27T21:07:40.803Z
@ctrl-alt-delor, well, I didn't name it.
Buffy
CC BY-SA 4.0
2022-12-26T23:14:29.830Z
2022-12-26T23:23:22.313Z
2022-12-26T23:23:22.313Z
Buffy
<p>I've just been prompted to think about this by reading this dated question: <a href="https://cseducators.stackexchange.com/questions/6459/jackson-based-ide-for-programming">Jackson based IDE for programming</a></p>
<p>But the issue had already been on my mind recently.</p>
<p>Why do attempts at &quot;visual designers&quot;, visual programming, and diagrammatic representations of programs persist?</p>
<p>I'm not talking about ad-hoc diagrams for human consumption, either to explain concepts or to supplement something that is found to be difficult to express in a particular programming language.</p>
<p>I mean visuals and diagrams that are systematic in some way, and which attempt to cover the same ground as written programming languages. A systematic approach which basically starts from the idea that <em>everything</em> is difficult to express in a written programming language, and therefore a visual method should be used instead.</p>
<p>It seems to me there have been a variety of schemes over many decades now, and all eventually seem to fall by the wayside.</p>
<p>Untrained novices seem not to be automatically drawn to such diagrammatic representations, and experts tend to shun them either as simplistic or as obscuring.</p>
<p>But they are often advocated for as something that somehow makes things easier - either for novices or for experienced practitioners.</p>
<p>What are the views and experiences of educators on the effectiveness of &quot;visual programming languages&quot;, either as teaching aids or as something that really helps productivity?</p>

CC BY-SA 4.0
2022-12-26T16:04:11.720Z
IDK about visual programming as a teaching tool, but I have used a visual designer to code finite state machines for an embedded project. Somebody\* once said, "Only the code can explain what the code does." What they meant was, programmers are lazy about keeping other forms of documentation up-to-date. We can only trust the source code to be truly accurate. OK, well, sometimes a diagram is a more intuitive explanation than a bunch of text. And, if the diagram _is_  the source code, then we can trust it to be up-to-date.  \[\*[Uncle Bob](https://en.wikipedia.org/wiki/Robert_C._Martin) maybe?\]
Solomon Slow
CC BY-SA 4.0
2022-12-26T16:30:05.127Z
@SolomonSlow, I don't want to make it sound like I'm against diagrams in principle. I use my visual and spatial imagination a lot, I know a good diagram when I see one, and I'd be inclined to resort to diagrams if I were teaching. But in terms of specifying instructions for the computer in general - in terms of programming - somehow it just doesn't seem to work. The question is actually on my mind because twice in the past year I've encountered reporting applications that do quite a bit, but lack a written representation of what, and it seriously impairs my oversight of them.
Steve
CC BY-SA 4.0
2022-12-27T20:53:40.640Z
Can you proof read and edit paragraph “Untrained novices seem not to be automatically drawn to such diagrammatic representations, whereas experts tend to shun them either as simplistic or as obscuring.” It reads as novices don't like it as opposed to experts that don't like it.
ctrl-alt-delor
CC BY-SA 4.0
2022-12-27T20:59:25.087Z
Christopher Alexander (the architect and author of the first pattern language book), has stated that words are much better than diagrams when expressing what is wanted in a design. Diagrams always accidentally specify arbitrary things. E.g it is impossible to show as straight line without giving it length. But with words we can say “straight line”. With the diagram we can draw the line, but have to add the words “not to scale”. The words alone are simpler.
ctrl-alt-delor
CC BY-SA 4.0
2022-12-27T22:15:11.240Z
@ctrl-alt-delor, it was precisely my intention to say that novices don't particularly like visual programming techniques either. The only novices I've ever heard about using JSP, for example, were specifically trained to do so by an employer - they were not spontaneously drawn to it.
Steve
CC BY-SA 4.0
2022-12-28T13:43:12.880Z
You can edit your question to make it clearer.
ctrl-alt-delor
CC BY-SA 4.0
2022-12-28T14:34:18.297Z
I edited the question as discussed, to make it clearer.
ctrl-alt-delor
<programming>
Why visual program design?
# Why visual program design?

(Asked by: username_0 on 2022-12-26)

I've just been prompted to think about this by reading this dated question: [Jackson based IDE for programming](https://cseducators.stackexchange.com/questions/6459/jackson-based-ide-for-programming)

But the issue had already been on my mind recently.

Why do attempts at "visual designers", visual programming, and diagrammatic representations of programs persist?

I'm not talking about ad-hoc diagrams for human consumption, either to explain concepts or to supplement something that is found to be difficult to express in a particular programming language.

I mean visuals and diagrams that are systematic in some way, and which attempt to cover the same ground as written programming languages. A systematic approach which basically starts from the idea that *everything* is difficult to express in a written programming language, and therefore a visual method should be used instead.

It seems to me there have been a variety of schemes over many decades now, and all eventually seem to fall by the wayside.

Untrained novices seem not to be automatically drawn to such diagrammatic representations, and experts tend to shun them either as simplistic or as obscuring.

But they are often advocated for as something that somehow makes things easier - either for novices or for experienced practitioners.

What are the views and experiences of educators on the effectiveness of "visual programming languages", either as teaching aids or as something that really helps productivity?

**Tags:** programming

> **Comments:**
> **username_1**: IDK about visual programming as a teaching tool, but I have used a visual designer to code finite state machines for an embedded project. Somebody\* once said, "Only the code can explain what the code does." What they meant was, programmers are lazy about keeping other forms of documentation up-to-date. We can only trust the source code to be truly accurate. OK, well, sometimes a diagram is a more intuitive explanation than a bunch of text. And, if the diagram _is_  the source code, then we can trust it to be up-to-date.  \[\*[Uncle Bob](https://en.wikipedia.org/wiki/Robert_C._Martin) maybe?\]  
> **username_0**: @SolomonSlow, I don't want to make it sound like I'm against diagrams in principle. I use my visual and spatial imagination a lot, I know a good diagram when I see one, and I'd be inclined to resort to diagrams if I were teaching. But in terms of specifying instructions for the computer in general - in terms of programming - somehow it just doesn't seem to work. The question is actually on my mind because twice in the past year I've encountered reporting applications that do quite a bit, but lack a written representation of what, and it seriously impairs my oversight of them.  
> **username_2**: Can you proof read and edit paragraph “Untrained novices seem not to be automatically drawn to such diagrammatic representations, whereas experts tend to shun them either as simplistic or as obscuring.” It reads as novices don't like it as opposed to experts that don't like it.  
> **username_2**: Christopher Alexander (the architect and author of the first pattern language book), has stated that words are much better than diagrams when expressing what is wanted in a design. Diagrams always accidentally specify arbitrary things. E.g it is impossible to show as straight line without giving it length. But with words we can say “straight line”. With the diagram we can draw the line, but have to add the words “not to scale”. The words alone are simpler.  
> **username_0**: @username_2, it was precisely my intention to say that novices don't particularly like visual programming techniques either. The only novices I've ever heard about using JSP, for example, were specifically trained to do so by an employer - they were not spontaneously drawn to it.  
> **username_2**: You can edit your question to make it clearer.  
> **username_2**: I edited the question as discussed, to make it clearer.  

---

## 4 answers

### Answer by username_3 on 2022-12-27. Score: 3 | Accepted answer

I'm an advocate for limited use of visual programming. First, for elementary and middle school kids, languages like Scratch (or variations, such as is used by Lego robotics) seem to work well.

I have no quantitative data, but I have taught it myself to middle school students, and I speak to a LOT of computer science teachers during the course of my duties, so I have some comfort in the assertion that it helps at these lower levels.

Second, there is a reason that devices like FSMs are traditionally diagram-based: they are extremely hard to flow when provided as text. So areas that traditionally use FSMs, such as animation controllers in Unity, naturally wind up in the visual programming sphere, sometimes augmented just a bit with written programming.

Finally, there are other environments where visual programming has entered the professional sphere, such as Blueprints in Unreal. They provide limited functionality, but the functionality they provide is a very useful subset, and (take this next with a grain of salt, I have used Unity but never Unreal) allow game designers to do more substantial work without having to ping the developers constantly.

It's hard for me to imagine that we, as highly visual AND highly verbal creatures, would uniformly find that either written programming or visual programming is always a better approach. We are excellent and processing information in both spheres, with somewhat different strengths in each. I would actually expect that, given the ideal circumstances, we would most naturally gravitate towards a combination of the two, such as the two major game engines have done.

> **Comments:**
> **username_0**: Your points chime with my preconceptions. Diagrams are useful for teaching beginners (not for industrial use), and they are useful to experts in limited cases (like FSMs) that involve a lot of "wiring" and for which there is no good textual alternative known which is as expressive as a diagram.  

---

### Answer by username_2 on 2022-12-27. Score: 2

Christopher Alexander (the [building] architect and author of the first pattern language book), has stated that words are much better than diagrams when expressing what is wanted in a design. Diagrams always accidentally specify arbitrary things. E.g it is impossible to show a straight line without giving its length. But with words we can say “straight line”. With the diagram we can draw the line, but have to add the words “not to scale”. The words alone are simpler.

Visual programming can however be useful as a way to teach programming. See [Scratch from MIT](https://scratch.mit.edu/) for young kids, [Snap from Berkeley](https://snap.berkeley.edu/), or many of their derivatives.


---

### Answer by username_4 on 2023-02-08. Score: 2

State diagrams equipped with an animation facility are great tools for communicating temporal behaviour. David Harel introduced [StateCharts](https://en.wikipedia.org//wiki/State_diagram#Harel_statechart) to add *hierarchy* and *concurrency* to overcome the inherent limitation in plain state diagrams - they did not scale well. Back in the day an expensive tool was developed that would make the would-be developer create the diagrams as if in a drawing program. That was a failure. Moreover, the original StateCharts had some semantic issues (leading to 95+ published papers on their semantics), nowadays resolved in, e.g., [SCCharts](https://rtsys.informatik.uni-kiel.de/%7Ebiblio/downloads/papers/pldi14.pdf) for which a family of IDEs is [available](https://rtsys.informatik.uni-kiel.de/confluence/display/KIELER/Overview). What these newer versions have in common is that the pretty diagrams are *derived by the tool* from the textual representation, i.e., good old-fashioned textual code.

**tl;dr**
A classical instance of visual programming has been retired in favour of textual programming augmented with powerful visualisation.


---

### Answer by username_5 on 2022-12-26. Score: 2

Probably the closest modern thing to what you want is UML (Unified Modeling Language). Lots of object oriented design gets expressed in formal or informal UML and there are a lot of tools for creating them. A google search for "object oriented diagramming" will turn up several options.

Flow charts went out of vogue a long time ago, along with common (all?) use of goto statements. The problem with both is that there are too many degrees of freedom with them, leading to a tendency toward short term solutions (quick & dirty) where long term software reliability and maintainability is required.

See [wikipedia for goto criticism](https://en.wikipedia.org/wiki/Goto#Criticism). David Gries (Cornell prof and important author) always referred to flow charts as "flaw charts".

It is too easy, with the old tools, to put bugs in and too hard to get them out.

I've built some pretty sophisticated stuff with OO (Java, Python, Ruby) but very simplified UML was always enough. Just enough to show the relationships between important modules.

A programming environment that integrates Java programming with simplified UML is [bluej](https://bluej.org). The site also includes many programming projects for beginners.

> **Comments:**
> **username_0**: I appreciate the answer, but I was primarily asking whether educators find these visual schemes to be *effective*, either as a complete alternative to written code, or as something where the design is done visually and then more or less mechanically translated into code.  
> **username_2**: UML has some good bits, but the U is a lie. It is not unified, it is a pile of diagram standards. Some useful, some just in there because of who was on the comity. There are other systems BON is more unified. There are also things that UML misses, such as pipeline diagrams, layer diagrams, …, etc, etc.  
> **username_5**: @username_2, well, I didn't name it.  

---

