As a "serious programmer", I'd be very happy to have a more graphical, more interactive programming experience as far as _output_ is concern. I'm happy to input textual expressions and definitions, but I'd like instant feedback and display of intermediate results as tables, graphs, trees, charts etc. Vital looks quite promising in the regard (though I've only browsed the website, and not used it). Spreadsheets are successful, I believe, because of the instant visual feedback they provide. An environment that worked in a similar way, but built upon a rigorous and high level language like haskell could well be a "killer app". Tim

-----Original Message----- From: Graham Klyne [mailto:GK@ninebynine.org] Sent: Thursday, November 13, 2003 10:03 AM To: Marcin 'Qrczak' Kowalczyk Cc: haskell-cafe@haskell.org Subject: Re: ANNOUNCE: Release of Vital, an interactive visual programming environment for Haskell

[Switching to haskell-cafe]

For "serious programming", I entirely agree.

But my view is that we are seeing some degree of programmability entering all sorts of everyday objects -- video recorders spring to mind as an early example -- and there's lots of work going on in the field of "ubiquitous computing". Many of these pervasive devices may be fire-and-forget, but I suspect many will not be. Graphical displays may be more common than full keyboards. So how is the user to be presented with options to enter programming information? I don't have any final answers here, but I do have an intuition that for many users, where the "programming" requirement is a simple but flexible composition of existing functions, that a graphical, self-documenting interface may be an appropriate response to the "video recorder programming hell" syndrome.

Some of my thoughts about this came from considering issues faced by a friend of mine who has recently wired his new home for "total data" (several kilometres of Cat5A cable in the loft!) -- it's all very well having all these intelligent devices around the home, but how to actually tell them what to do? Opening a door may signal that a light should turned on, or an alarm should be set off -- how to describe the distinction? (Assuming the owner is not an experienced programmer.)

Finally, as evidence for this view of user interfaces, I note that for tasks like computer system administration, graphical interfaces have pretty much taken over from the old command-line-and-text-file approach. Even Linux systems have graphical front-ends for most of the common configuration, even though, for an experienced sysadmin, the text-based versions are generally quicker to set up and understand what's happenning. In short, it's the occasional user, not the full-time expert, who may be better served by a non-textual approach.

#g --

...

W li¶cie z ¶ro, 12-11-2003, godz. 11:06, Graham Klyne pisze:

...

I've sometimes thought that a functional language would be the ideal platform to usher in a purely graphical style of programming;

I don't understand why so many people talk about graphical

At 23:56 12/11/03 +0100, Marcin 'Qrczak' Kowalczyk wrote: programming,

...

i.e. putting together functions, arguments, definitins etc. with the mouse instead of the keyboard, drawing arrows instead of naming etc.

No wonder it didn't succeed. It would be much less convenient than typing text and less readable too.

-- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell

------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe