[Haskell-beginners] appropriateness of haskell for GUIs

[Peter Verswyvelen]

On Sat, Mar 21, 2009 at 1:30 PM, Michael Mossey <mpm at alumni.caltech.edu>wrote:

> I can imagine that GUI programming is no easier (yet). It is inherently
> very "stateful." GUI's have modes, such as which screens are displayed,
> which dialogs are displayed, which options within those dialogs are valid
> given the other state of the program, etc. When I write GUIs, I often
> diagram them as state machines to get a handle on what's going on.


So, I'm not familiar with GUI programming on Haskell, but would you say the
> statefulness of GUIs (in their typical implementations) is the reason they
> are no easier on Haskell?


Even if you want to see GUIs as state machines, it is perfectly possible to
make pure stateful GUIs in Haskell without using IO.

I guess the problem is that a purely functional GUI library - be it stateful
or continuous- is only useful if it comes with lots of GUI controls, and
writing all these controls is a big task. It is much easier to wrap an
existing C toolkit to get the job done, even if it means making your hands
dirty :-) Furthermore modern GUI toolkits like perform real time animation,
styling, data binding, layout, etc... so this is a huge undertaking.

That being said, I think many many Haskellers really would love to use a
purely functional GUI toolkit, but unfortunately, a production quality
toolkit does not exist yet. I guess building all controls needed for a GUI
library could be a global community effort if we all agreed on a good FRP
(=functional reactive programming) library to build the GUI on, but
currently no clear winner exists.

I strongly prefer to use qtHaskell because I'm familiar with Qt, and Qt is
> extremely capable. For example, it can draw text and shapes with
> antialiasing, which will be great for a music score editor. Music scores
> have lots of small shapes to fit on the screen, and antialiasing will
> provide ease of reading. I don't know how much of Qt is implemented in
> qtHaskell, or whether the latest version of Qt (4.4) is implemented.


Cairo - part of GTK - can also do that, but I expect it to be slower than Qt
(at least on Windows)

My personal opinion: GUIs don't really "work" either in imperative or
functional programming. But we can make it work in the imperative world
because we can hack around the problems.


Thanks,
> Mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/beginners/attachments/20090323/b44d5678/attachment.htm