Graphical Programming in (Mis)use

When I got the Lego Mindstorms robotics kit that I have been blogging about before (1,2,3), one of my goals was to try my hands on some graphical “model-driven” programming. Thanks for the various tips for other more traditional programming environments that I have received over comments, Facebook, and personal email. But my main goal was really to try to use the NXT environment as a graphical, domain-specific, rapid programming environment. Having played around with some simple projects for a couple of months now, it is clear that somethings are easier to do than others.

Back in the late 1980s, in what seems to have been a golden era of software innovation, there were a number of companies trying to sell graphical programming environments for the graphics-oriented Macintosh computer. Makes sense, right? I remember that I did not think so at the time, and the reason was that things tended to look more complex in a visual system than when expressed as plain text. I think one of the examples I saw was Prograph, where unwieldy flow charts replaced nice and dense if-then statements.

Today, twenty years later, it is hard to dispute the success of model-driven and graphical environments like MatLab, LabView, and others. Dataflow is very good paradigm for many things in signal processing, and it fits very nicely with graphical representations. UML statecharts do express state machines in a pretty readable manner which is far superior to any particular code encoding of the same information.

However, I think the key here is that the languages are domain-specific to a large extent. General-purpose programming is still not really feasible in a graphical way, and I doubt it will ever be. You also need to “go with the flow” in these systems to get full benefit from them. If you start to think in imperative coding terms, you tend to quickly get lost… Here is a personal example that a friend (who will remain anonymous to protect the guilty) and I cooked up in NXT, trying to code an algorithm to guide a robot along a line. The picture both contains the graphical representation and the approximately equivalent imperative-style code.

All the little red boxes are value reads, writes, and manipulations. It is kind of elegant that you can pass values on from one block to the next, but overall the graphical representation must be said to be totally unreadable. The logic was pretty good, actually, but it did not do things like you are supposed to do in Mindstorms. Rather than a reactive “act wait act” cycle, we tried to code complex loops.

I guess this is an example of the old saying that a good (or determined) programmer can write FORTRAN in any programming language. As an aside, I recall a Russian-schooled professor I had as an undergraduate who managed to abuse Prolog to create a deterministic loop from its backtracking system. Ugly indeed, but also quite an impressive feat of semantic wrestling.

The Mindstorm-style solution to following a line was found by a bit of Googling, and for the robot that I built a fairly (not entirely, though) robust program looked like this. Credit to http://www.nxtprograms.com/line_follower/steps.html for the original program that I had to modify just a bit to work with Mindstorms NXT 2.0.

In a sense, this program is bad since it obviously relies on non-functional properties of the NXT environment which are not semantically specified (i.e., the speed of sensing and how to drive the motors the fastest). However, the sense-act loop with no state saving is the right way.

Obviously, other graphical environments will have other strengths and weaknesses, but I think that this is a nice illustration that the typical constructs of general-purpose programming languages are poor fits for graphical visualization. Variables are simply not very visual in their nature…