<div class="gmail_quote">On Wed, Mar 24, 2010 at 9:47 PM, Richard O&#39;Keefe <span dir="ltr">&lt;<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
On Mar 25, 2010, at 2:33 PM, Ronald Guida wrote:<br>
... a version of map as text ...<br>
... a diagram ...<br>
<br>
The thing that strikes me forcibly is that the diagram<br>
is much bigger than the text.  Not only that, but if<br>
I am reading it correctly, the text has three lines,<br>
a type specification and two cases, and the diagram<br>
covers only one of the two cases.<br></blockquote><div><br>I agree, absolutely!  One of the things I don&#39;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 <i>very</i> verbose hardware design language.  On the other hand, sometimes one can visually &quot;read&quot; a schematic faster than reading the corresponding code.  My preference is to describe digital circuits using hardware design language.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This isn&#39;t Ronald Guida&#39;s fault.  In fact his is a very<br>
nice looking diagram, and I could figure it out without<br>
his explanation of the notation, *given* the textual<br>
version to start from.<br>
<br>
I&#39;ve seen several visual programming tools, including<br>
e-Toys in Squeak, and they tend to be really cool ways<br>
to quickly build programs with trivial structures.<br>
<br>
(I did not say trivial programs: you can build useful<br>
programs that do highly non-trivial things, when the<br>
things that are primitives _for the notation_ are<br>
capable enough.  Some data mining products have visual<br>
wire-up-these-tools-into-a-workflow, for example.)<br></blockquote><div> </div><div>I find it easier to &quot;type&quot; what I want to do, using a textual programming language, rather than having to &quot;drag and drop&quot; 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.)<br>
<br></div></div>-- Ron<br><br>