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. Jan