Web Rarely

I recently purchased a copy of Microsoft Visio. It's a nifty tool that lets you make very sharp-looking diagrams. But I bought it because it does more than just let you make diagrams. It also lets you associate custom properties with everything, and access the whole diagram programmatically. When I worked at Trustium Corp., we used Visio to create state machine diagrams representing transactions involved in buying and selling real estate. Each state machine had the various actors and the steps they'd have to go through to complete the various tasks, documents they'd need to sign, etc. Much of the state machine was conditional in a typical task, depending on who was involved, the values entered into online CAR contracts, etc, and those conditionals would affect the contents and layout of further documents and the paths taken through other tasks. It was a very powerful system. That, combined with the online forms, digital signatures, process tracking, and non-repudiation system, was our core product. It never really took off though, because we spent so much time building things for other people just to pay our expenses that we never had the opportunity to really market our own product.

Anyway, the massively complicated state machines involved were created as simple diagrams in Visio. We created some custom shapes, which were really just some of the built-in Visio shapes with custom coloring and naming, and some custom properties applied. After creating or editing a diagram, we'd just click a button inside Visio to translate the diagram into a state machine stored in a SQL database. The button was powered by a bit of code that we wrote to walk through the diagram and convert the nodes to rows in the database. It was so simple and intuitive that anyone in the office could use it, and was just so damned cool. Ever since then, I've been enchanted with the idea of reducing complex data and processes to simple diagrams in Visio.

Trying to think of what I could do with my new toy, my thoughts naturally turned to the projects I've been working on recently -- compilers and a dynamic language runtime. I had sexy fantasies of creating a slick graphical programming language. But I was somewhat sobered by the knowledge that very smart people have been working on that problem for a long time, and they haven't produced anything even remotely useable yet. I figured I'd doodle on some graph paper, but I quickly remembered that I'm no good at that. So I figured I'd doodle inside WordPad instead, and then I figured I might as well throw it up on my blog. So here it is: my doodling!

Graphical programming can be done fairly easily by emulating the LISP language. The entire LISP language can be built from the ground up on only a few small primitives, and this idea can be extended into the graphical programming space. I can easily imagine building up code the way you would LISP. Graphical objects would represent nodes in a kind of virtual parse tree, and the primitives would be provided as predefined nodes that you can use. All other nodes could be built from the primitives. Each node would have defined connection points, which correspond to inputs and outputs.

For instance, you could use the lambda primitive node to construct a variable binding (ie, "let") node. Then, whenever you needed to bind a variable, you'd simply drop a "let" node into the program. You might then construct an iterator, like common LISP's "do" construct. You could then build a simpler "for" loop on top of that, or a loop that specifically loops over a list. Each of these nodes would be constructed and stored as new shapes that could be dropped into the program. The next time you need to iterate through a list, you just drag a list iterator into the program, hook up the input list, the body node, etc, and there you go.

It sounds simple, effective, and elegant. And it is. Unfortunately, that doesn't cut it in the programming world, because it's already simpler and more effective to just type the equivalent code into a text editor. Had a graphical programming environment like the one I just described existed 25 years ago, it would have still been outclassed by the machines running simple text editors and LISP interpreters. It'd have been pretty, a cool toy, and perhaps even a good learning environment, but not productive.

Another way the graphical programming environment I described is inferior to a text editor is that it's very wasteful with screen space. The equivalent code in a text editor has a much higher information density, so screen space is put to better use. Graphical programming takes longer to create basic elements (nodes), since you have to drag them with a mouse and hook up their inputs and outputs. That, combined with the fact that fewer basic elements can fit on the screen, means that each basic element would have to do a lot more to compete with textual programming. Creating a higher-level language where each node represents a significant chunk of code would certainly make this possible, but very high level programming languages tend to have a rather restricted set of expressible programs, meaning that they're not practical for real-world use.

So in order for it to be both very high level and still very powerful, it would have to be intelligent. Wouter van Oortmerssen (http://wouter.fov120.com/) has done a substantial amount of work in this area. One idea he implements is "programming by example", where you show the computer a single recursion of a specific instance of a quicksort, say, and it extrapolates to get the general idea. You can see both the quicksort and "succ" algorithms implemented in a programming by example style on his Aardappel page. It's a very cool and powerful idea for algorithm design, but I'm not sure if it's applicable to real-world programming tasks, which are much less algorithmic and can't be so easily deduced from formulas, I think.

One idea I had is to merge the design and development steps. A program could be designed in a graphical tool like Microsoft Visio, breaking it logically into modules, say, and you could zoom in on a module to see it broken into classes, and zoom in further to see classes broken into functions. Then, you could implement the functions using graphical programming techniques. The whole graphical design could be decorated with annotations, flowcharts, bug reports, UML diagrams, data flow graphs, user feedback, threat models, and other non-executable diagrams and documents. Those could be populated from a database, too, with the bugs coming from a bug database and the user feedback coming from the QA team, etc, with realtime updates in the background, creating little bug icons and user feedback balloons attached to bits of your code. Those data sources could all be linked together, making it a very powerful environment, with everything you need to build the program available at once from within the same user interface. It's too bad that the actual construction work, where you do the down-and-dirty coding, is so difficult to do in a graphical manner. Perhaps a compromise could be reached that combines an integrated design environment with textual code editing, where you'd double click on a leaf in the tree, like a function, to edit its associated code in text form.

So I didn't actually get any good ideas for a graphical programming language. The graphical LISP idea came almost immediately, but it's so inferior to textual programming that it's not really worth implementing, except as a toy. But hot damn, I do like that integrated design environment idea.