[GUI] GUI meeting at ICFP?

Simon Peyton-Jones simonpj@microsoft.com
Thu, 24 Jul 2003 09:23:42 +0100


| on my side). In hintsight this was a very negative
| development as it encouraged people to follow their own
| convictions and implement their ideas in the hope that their
| approach is adopted by the masses.

I don't think that the recent work on GUI implementation is a negative
development at all.  Its great!  It gives new information about what
works and what doesn't, and it adds to the raw material from which
something common can be forged. =20

However, I want to articulate once more what I think we are trying to
achieve.

	* I am Joe Programmer.
	* I want to write a Haskell program with a GUI.
	* What do I do?=20

Fact:  A GUI interface is big, so it's hard to change my=20
	 program from one GUI library to another.

Therefore: my absolutely top priority is to use a library
	that I believe will continue to exist, and be supported,=20
	at least on the platforms I care about.

Next priorities are:
	- readily available to people who want to modify my source code
	- available for more than one Haskell implementation

Bottom of the list is:
	- functionality
	- native look and feel

Priority 1 advises strongly against a GUI library supported by one
person alone, no matter how talented.  As Joe Programmer, I'm very, very
keen to use a library that is cherished, developed, and supported by
many people.  They may each do different tasks, but multi-party buy-in
gives me confidence that it's not going to go away when (say) Daan or
Krasimir gets hired by a Wall Street finance house.


Priority 1 also argues in favour of a Haskell GUI library that is, in
turn, built on top of a non-Haskell GUI library which is itself
multi-platform, being actively developed, and likely to persist. We
don't have enough effort to re-implement this stuff!  (As I understand
it, this is one of the attractions of the Wx approach.)

An internal goal (irrelevant to Joe Programmer) is that the
Haskell-GUI-library design should be high-level enough that it can be
implemented on top of more than one underlying non-Haskell GUI library.
That is a worthy goal, but the discussion I have seen has made me
conclude that it is simply too difficult to meet.  Let's abandon it!
Joe doesn't care.  I think it'd be fine to pick *one* library (Wx,
Motif, X11, Tk, whatever) and allow that to influence the design of what
gets exposed to the Haskell programmer.  Apart from anything else, it
makes life easier by taking a lot of design decisions (for better or
worse) out of our hands.  Once an underlying library is chosen, many
things get fixed.



I'm not against sexy, interesting designs built by one person -- far
from it -- but I desperately want One Thing that is multiply supported,
even if the One Thing is not very sexy. =20

So I beg the members of the GUI task force to put aside considerations
of doing the Best Thing, and concentrate your *joint* efforts on doing
One Thing.  That entails compromise (e.g. picking one non-Haskell
library to build on), but it needn't conflict with parallel individual
efforts. =20

What I fear, though, is that the key players become so committed to
their particular approach that we never get One Thing.  Instead we get
Many Things, each supported by one person.  And that is just no good for
Joe Programmer.  (The pre-Haskell situation was many languages each
supported by one group, and that was no good either; hence Haskell.)

This is a big issue: it's really holding up Haskell.

Simon=20