2
$\begingroup$

I've just been prompted to think about this by reading this dated question: 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?

Improve this question
$\endgroup$
7
  • $\begingroup$ 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 maybe?] $\endgroup$
    – Solomon Slow
    Dec 26, 2022 at 16:04
  • $\begingroup$ @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. $\endgroup$
    – Steve
    Dec 26, 2022 at 16:30
  • $\begingroup$ 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. $\endgroup$
    – ctrl-alt-delor
    Dec 27, 2022 at 20:53
  • $\begingroup$ 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. $\endgroup$
    – ctrl-alt-delor
    Dec 27, 2022 at 20:59
  • $\begingroup$ @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. $\endgroup$
    – Steve
    Dec 27, 2022 at 22:15

4 Answers 4

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – Steve
    Dec 27, 2022 at 10:19
1
$\begingroup$

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. 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. The site also includes many programming projects for beginners.

Improve this answer
$\endgroup$
3
  • $\begingroup$ 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. $\endgroup$
    – Steve
    Dec 27, 2022 at 9:16
  • $\begingroup$ 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. $\endgroup$
    – ctrl-alt-delor
    Dec 27, 2022 at 21:06
  • 1
    $\begingroup$ @ctrl-alt-delor, well, I didn't name it. $\endgroup$
    – Buffy
    Dec 27, 2022 at 21:07
1
$\begingroup$

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 for young kids, Snap from Berkeley, or many of their derivatives.

Improve this answer
$\endgroup$
0
1
$\begingroup$

State diagrams equipped with an animation facility are great tools for communicating temporal behaviour. David Harel introduced StateCharts 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 for which a family of IDEs is available. 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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.