ANNOUNCE: Release of Vital, an interactive visual programming environment for Haskell

Tim Docker timd at
Thu Nov 13 21:42:32 EST 2003

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


> -----Original Message-----
> From: Graham Klyne [mailto:GK at]
> Sent: Thursday, November 13, 2003 10:03 AM
> To: Marcin 'Qrczak' Kowalczyk
> Cc: haskell-cafe at
> 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
> --
> At 23:56 12/11/03 +0100, Marcin 'Qrczak' Kowalczyk wrote:
> >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 
> 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 at
> >     ^^
> >
> >_______________________________________________
> >Haskell mailing list
> >Haskell at
> >
> ------------
> Graham Klyne
> For email:
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at

More information about the Haskell-Cafe mailing list