Visual Haskell

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