Rob MacAulay a propos of the visual/dataflow programming:
> Visual programming sounds nice, but in practice it is of limited
> use. If you have a smallish number of modules to link together, you
> could do this as easily by hand-coding. If you have a larger number
> of modules, you probably ought to think about simplifying the
> system!
> Rob MacAulay
> Cambridge
First, there are least two different concepts in visual programming.
The first one is the visual building of event-drivent interfaces,
- you know what i mean - putting widgets on the screen and filling
the popped-up forms for the callbacks. Visual Basic or C++, NetBeans
or other Java Builders, etc. I am not particularly interested in this,
although it is an important domain.
I spoke about the dataflow-style languages, the "circuit builders":
Simulink, Scilab/SciCos, WiT, Khoros, IBM Data Explorer (Now Open
Source) a diagrammatic layer in MathCad, LabView, etc., (+ the defunct
Java Studio).
And, of course, the notorious Visio used by some Haskell gurus
around, for example by Eric Meijer.
The whole idea is to connect together some modules through *several*
data paths. Making it through a linear, textual program is of
course possible, but unwieldy. Please, look at the definition of
a Simulink "circuit" (M-file). It is frustrating. Dataflow languages
are mostly functional, without side-effects, with a kind of laziness
in the sense that the order of execution is not specified - a block
should wait for the data.
If the block present themselves as "objects", not functions on
the screen, their re-using consists in packaging smaller modules
in a bigger one, and you will end up with a large hierarchy, which
might to be difficult to code manually.
So, I disagree, the 2-dimensional, graphical programming has a nice
future, although the dataflow languages like Lucid won't ever
become very popular.
I am quite sure that such a system could be built in Haskell or
Clean in a clean way. BTW. already in Abelson&Sussman^2 you can
find such constructions in Scheme in the context of constraint
programming.
Jerzy Karczmarczuk
Caen, France.
