An introductory course in computer programming (1965)

I used to be in the camp thinking that we should be using way more visual programming tools. I even worked at a startup company building a "software factory" (essentially a tool for generating a DB and an accompanying front-end which can load a metamodel for that DB and builds an interface for it).

Nowadays I do think that visual programming is better for domain-specific purposes. I also think that for many purposes code is a suitable abstraction layer on top of machine instructions. Meanwhile abstraction means removing nonessential detail, however for a general purpose programming language one cannot predict which features are essential in a specific application. That's why visual programming is working in domain-specific areas, because in that case you can often decide which details are nonessential.

There is the Russian DRAKON programming language, might be worth having a look at it.

I don't know about this. At my last job, one of the very first problems dropped in my lap was to fix a debugging tool that had been mostly written in Workflow Foundation, a flowchart-based programming environment for .NET that isn't domain-specific, esoteric, or intended for children. It was the tenth circle of Hell and almost drove me to a nervous breakdown in my first month on the job. Despite how often I quote Joel Spolsky's "never rewrite the project from scratch" essay, I threw the whole thing out and wrote it again, and was much better off for doing so.

Now, certainly the specific failings of WF, and the bast^H^H^H^H person who wrote the tool were partially to blame here, but even with all that in mind, the experience has permanently soured me on visual programming. It has all kinds of flaws-- it's harder to reason about, harder to debug, harder to comment, and harder to quickly modify that plain old source code. If there was some trade-off, an upside for all that trouble, maybe it would be worth it, but I can't see one.

Until someone can come up with a way to draw faster than we can type, programming will always tend towards text.

I am not sure I see much advantage in visual programming on the small scale, ie little boxes for control flow.

But I badly want it for bigger, architectural concerns. Why do our IDEs just display lists of files in a pane? I've often day dreamed about an IDE where the system is visually modeled as a network of modules/objects, with edges representing dependencies, and you'd double click on a module/object to edit its source code.

Somewhat relevant: http://prog21.dadgum.com/69.html

In a way APL is 'flowchart based programming', the flow is so simple it can be used to express what otherwise would be a program with multiple constructs on a single line. Each APL character then becomes a 'box' in your flowchart. Sort of a minimalist graphical representation of what the program does.

A unix command line gives me a similar feeling with processes feeding their output into other processes each doing some kind of transformation on their input with the | character functioning as the lines in a flowchart.

Now obviously that has some differences with an actual flowchart (such as 'if' statements) but the effect is close enough that there are some parallels.

Have you taken a look at LabVIEW? I used it pretty heavily back in grad school.

It's a graphical programming language, you connect wires between modules and operators.

Its weird to get used to at first, especially if youre proficient in text-based programming languages, but when you get a feel for letting the program flow drive the logic, you can do some pretty powerful things.

The general idea is that you have a "front panel" that controls user input, and then the back-end programming. Eg, Boolean inputs can be a variety of switches, outputs can be lights and LED's. Floating inputs can be knobs and sliders, outputs can be displays, meters, bar graphs. Very easy to add plots that update in real time.

It's popular with lab research and data acquisition users, since you can easily whip up nice UI's, and many producers of laboratory hardware provide LabVIEW drivers.

You can also easily create advanced techniques or data structures too. Eg, wrap a state machine inside a queue widget, for a "Queued State Machine".

Some drawbacks are that it's proprietary commercial software, and the 'code' can easily become a tangled mess of wires.

http://www.ni.com/labview/

Example implementation of a state machine : http://www.ni.com/tutorial/7595/en/

Visual or graphical programming environments have useful applications, but I think they're always going to be niche. My kids had a lot of fun with Scratch for example, it's a lovely way to learn programming.

The big problem I see with visual programming tools though is that they prescribe the tools you can use to work on the system. I can work on the same Python scripts on Windows, Unix and iOS, in a windowing environment or a console. I can use Submlime Text, Vi, EMACS, Notepad++, whatever I want and configure them however I like. Syntax highlighting even visually distinguishes different aspects of the code in useful ways that even parallels some of the features of graphical coding environments. I can even generate code from other code, or use refactoring tools.

If your graphical tool generates text or something like XML then ok, you can do processing on that, but which is authoritative? The graphical representation or the underlying document? Now all you have is a fancy editor for what's really a text format anyway.

So I think in a lot of ways visual tools complicate things in some ways as much or more than they simplify them in others. I suspect that the domains in which these trade offs prove to be worthwhile are fairly limited.

I have never worked with Unity so I wouldn't know.

That being said, I think there may be a niche for visual programming tools when developing visual stuff. I'm old enough to remember Delphi, and also I made a few games in Flash back in the day. In both cases you would arrange visual elements, and you would attach stuff like event handlers written in a "real" programming language. I think the reason that it worked was that the visual part would be describing structure, not algorithms. In the same way that HTML is pretty good for describing UI elements without pretending to be a full fledged programming language. I'm not sure this division of labor would apply to Unity as well but I would presume so since it makes a lot of sense.

As for Scratch, I see it more as a real programming language but with a visual editor that makes it easy for beginners to compose programs by dragging and dropping. I think the tradeoff is great for beginners: makes the constructs visible and avoids syntax errors. I don't think it would scale to large projects, but that was never the point.

BTW, remember Logo from my school in the 1980s. I even seem to remember that we had the real, physical turtle at some point, able to draw lines on a sheet of paper. Or maybe my memory is deceiving me.