On Wed, Mar 24, 2010 at 9:47 PM, Richard O'Keefe <o...@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.) -- Ron
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
