On Wed, Mar 24, 2010 at 9:47 PM, Richard O'Keefe
On Mar 25, 2010, at 2:33 PM, Ronald Guida wrote: ... a version of map as text ... ... a diagram ...
The thing that strikes me forcibly is that the diagram is much bigger than the text. Not only that, but if I am reading it correctly, the text has three lines, a type specification and two cases, and the diagram covers only one of the two cases.
I agree, absolutely! One of the things I don't like about schematics (for digital circuits anyway) is the fact that a schematic is often bigger than the corresponding VHDL code, and VHDL is a *very* verbose hardware design language. On the other hand, sometimes one can visually "read" a schematic faster than reading the corresponding code. My preference is to describe digital circuits using hardware design language.
This isn't Ronald Guida's fault. In fact his is a very nice looking diagram, and I could figure it out without his explanation of the notation, *given* the textual version to start from.
I've seen several visual programming tools, including e-Toys in Squeak, and they tend to be really cool ways to quickly build programs with trivial structures.
(I did not say trivial programs: you can build useful programs that do highly non-trivial things, when the things that are primitives _for the notation_ are capable enough. Some data mining products have visual wire-up-these-tools-into-a-workflow, for example.)
I find it easier to "type" what I want to do, using a textual programming language, rather than having to "drag and drop" and then draw lots of wires. I feel the bigger (rhetorical) question is: At the level of code, what good are visual programming languages? (To clarify, I know that diagrams are indispensable for describing designs. The question pertains to actual source code.) -- Ron