ANNOUNCE: Release of Vital, an interactive visual programming environment for Haskell
Dear Haskellers, I am pleased to announce the release of Vital, an interactive visual programming environment based on Haskell. Vital provides the user with a workspace within which Haskell expressions and declarations can be located and their values displayed textually or graphically. The display is 'live' in the sense that the effects of graphical Copy and Paste operations carried out displayed values are automatically reflected in the Haskell source code. The long-term aim of the Vital project is to make Haskell available in a form that supports the open-ended, incremental style of program development that end users (engineers, scientists, analysts, etc.) often prefer. It may also be useful in teaching Haskell. This release of the Vital system is available from: http://www.cs.kent.ac.uk/projects/vital/ The site includes screenshots and a downloadable implementation with demo programs. If you happen to have Java installed on your machine, you can (in principle!) run the Vital interpreter and these demo programs simply by clicking on this link http://www.cs.kent.ac.uk/projects/vital/download/start.jnlp Enjoy! Keith Hanna
This looks like much fun. I took a quick look at the screenshots, but don't see any provision for graphical display of *programs* -- is there? I've sometimes thought that a functional language would be the ideal platform to usher in a purely graphical style of programming; there have been a few attempts over the years to do purely graphical programming, but they seem to founder somewhat on impedance mismatch between static visual presentation and dynamic behaviour of an imperative program, and I could see referential transparency eliminating some of these difficulties. Also, one could very easily imagine a graphical representation of a "point free" style of programming, with its emphasis on combination of functions. The Lego Mindstorms system is representative of the kind of environment where I think graphical and functional styles could merge very neatly. #g -- At 18:34 11/11/03 +0000, Keith Hanna wrote:
Dear Haskellers,
I am pleased to announce the release of Vital, an interactive visual programming environment based on Haskell.
Vital provides the user with a workspace within which Haskell expressions and declarations can be located and their values displayed textually or graphically. The display is 'live' in the sense that the effects of graphical Copy and Paste operations carried out displayed values are automatically reflected in the Haskell source code.
The long-term aim of the Vital project is to make Haskell available in a form that supports the open-ended, incremental style of program development that end users (engineers, scientists, analysts, etc.) often prefer. It may also be useful in teaching Haskell.
This release of the Vital system is available from: http://www.cs.kent.ac.uk/projects/vital/
The site includes screenshots and a downloadable implementation with demo programs.
If you happen to have Java installed on your machine, you can (in principle!) run the Vital interpreter and these demo programs simply by clicking on this link http://www.cs.kent.ac.uk/projects/vital/download/start.jnlp
Enjoy!
Keith Hanna
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Graham Klyne writes:
This looks like much fun. I took a quick look at the screenshots, but don't see any provision for graphical display of *programs* -- is there?
At present, there isn't. But plans are to incorporate a graphical style of programming, much along the lines of the Dami and Vallet paper on "Higher-order functional composition in visual form" http://citeseer.nj.nec.com/dami96higherorder.html
I've sometimes thought that a functional language would be the ideal platform to usher in a purely graphical style of programming; there have been a few attempts over the years to do purely graphical programming, but they seem to founder somewhat on impedance mismatch between static visual presentation and dynamic behaviour of an imperative program, and I could see referential transparency eliminating some of these difficulties.
I agree. A graphical programming style is essentially a declarative one, and so needs to be coupled with a purely declarative programming language -- and of course a functional programming language is ideal for this.
Also, one could very easily imagine a graphical representation of a "point free" style of programming, with its emphasis on combination of functions. The Lego Mindstorms system is representative of the kind of environment where I think graphical and functional styles could merge very neatly.
I think many potential uses of functional programming languages, who might find the functional composition dot operator a bit foreign, do indeed feel perfectly at home linking chains of function-boxes together. Graphical programming has a lot going for it. Keith Hanna
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@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
"Marcin 'Qrczak' Kowalczyk" writes:
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.
I think that some visual notations are more readable than text (but not all). In particular, if you try to teach lambda calculus or type inference to beginners, visual notations can be extremely helpful. Consider, for example, VEX [1], which is a visual notation for lambda calculus, it makes the difference between bound and free variables very easy to discern and it saves you from renaming during beta reduction. -- Martin [1] Citrin, W. and Hall, R. and Zorn, B. Programming with Visual Expressions 11th IEEE Symp. on Visual Languages, 294-301, 1995
participants (4)
-
Graham Klyne -
Keith Hanna -
Marcin 'Qrczak' Kowalczyk -
Martin Erwig