Mon, 2 Apr 2001 17:37:35 -0400 (EDT)
On Mon, 2 Apr 2001, Jason J. Libsch wrote:
> The reason that this paper so peaked my interest is that i have been
> working on a system that is tremendously similar to the one described in
> this paper- it's as if Dr. Reekie Van Eck phreaked my head or notebooks
> (unfortunatly, my designs have not progressed past pen and paper.) from
> the other side of the world. My take on the project is that such a
> language would be the ideal langauge for begining programmers.
The pictures in the paper look somehow familiar to what
I had invented and implemented in Smalltalk once upon
a time for a commercial product. It was more of
a hack, but a good hack, I believe.
This perhaps gives me a right to these two comments:
If you try to be too generic you might end up with
something that is too complex for a beginner but too
dumb for an expert user. I've seen two Smalltalk
packages which attempted connecting "phone books" to
"editors" and to other gimmicks and would end up
with some incomprehensible jungle of wires, inputs
and outputs .. and some limitations that would
force you to do textual programming anyway.
However, for a specific application domain this should
work perfectly well. My experience with my own package
was such that the visual interface was a high selling
point, and the salesmen loved it too: they could
use it to design all sorts of demos and then hand them
over to their junior people to carry on with the demos.
So perhaps you would do better if you'd tone down your
entusiasm a bit about generality of visual programming
("an ideal language for beginning programmers") and
focus on some domain specific applications instead.
This does not mean that you could not reuse the
framework. Quite to contrary! For example, I had
supported two different libraries of nodes (with
pretty icons): one for DSP and another for simulation
of noise control in ventilation systems. Two different
applications, two different audiences, two different
libraries, but the framework was the same.