A favourite subject for Ph.D. dissertations in software engineering is graphical, or visual programming. […] Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will.
tl;dr: It gets messy. Fast.
Not too long ago I was having lunch with a friend I hadn’t talked to in a while. He had been to a conference organized by the game development industry where he saw a company demo a visual programming tool for the Unity engine (I’m not 100% sure, but I think it was PlayMaker).
The tool allowed you to instead of having to painstakingly type out commands, simply drag a couple of boxes on a workspace, select some options and draw arrows between them. It’s worked very much like schematic tools used for programming FPGAs.
On the surface the idea seemed great and the demos were more than impressive. Instead of having to remember syntax and method names, you could simply browse through a list and find what you were looking for. Yet, I was still not convinced.
The basic problem is, as Frederick Brooks brings up in his book, that flowcharts are a very poor abstraction of software structure. They work fine for simple, trivial programs like the demos that the company showed my friend. But let’s be honest: very little software in the real world outside of a spreadsheet document is actually that simple.
Visual programming reminds me of this time when we designed and built a 4-bit computer out of nothing but NAND-gates in university. We started out with a few full adders and the schematic looking nice and clean. But as we kept on adding functionality the number boxes and the number of wires connecting the different boxes together grew to a horrifying amount. What was once a simple schematic had turned into a horrible abomination that was impossible, even for its creators, to get a grasp of. I know that it can be hard to return to code that you’ve written after a few months of not looking at it; but a schematic? That’s something I wouldn’t even consider doing.
The fact that text works better in the long run is something people discovered a long time ago in other fields. That’s why
VHDL Verilog is more popular than the schematic based approaches I mentioned before. Graphical stuff at the abstraction level that we have to deal with in software just gets too messy too fast. Modularization does solve some of the problems, but it’s too hard to do right and it’s too hard to clean up after someone has done it wrong.
So is visual programming all bad? Well, no. It does bring with it a few benefits.
As I mentioned before, not having a syntax or an API that you have to memorize is great. Especially for people that aren’t programmers or interested in programming. It also works well when you’ve got good modules that make your program seem trivial. I suspect that for the sort of games/applications that PlayMaker’s users are creating, it works more than just well. And from what I understand, PlayMaker also supports a hybrid approach where you can still write the code and interface it with the visual code. Perhaps this brings out the best of both worlds?