On Sat, Mar 21, 2009 at 1:30 PM, Michael Mossey
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