On Wed, Mar 24, 2010 at 9:47 PM, Richard O'Keefe
<ok@cs.otago.ac.nz> wrote:
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.)