None of them are very satisfying. I've used Gtk2Hs a fair amount, and it is solid. Conceptually it's very similar to the wxHaskell bindings (directly inspired b

None of them are very satisfying. I've used Gtk2Hs a fair amount, and it is solid. Conceptually it's very similar to the wxHaskell bindings (directly inspired by, if I'm not mistaken.) Of the three major cross-platform toolkits, Gtk+ is the most compatible with Haskell on account of it's C roots. Gtk can be used in a very procedural, not very OO kind of way. Since subclassing in C is such a bitch, Gtk+ is fairly easy to use without doing so: create some widgets, set their callbacks and go. Works fine from the IO monad, and using lambdas for the callbacks makes it actually quite enjoyable to use compared to C or C++ (as I imagine it is from OCaml, Lisp or any other such language.) Qt on the other hand is very OO. You define the behavior of your widgets by subclassing. There are signals and slots, which are basically callbacks and thus very FP-friendly, but there are many things for which Qt doesn't use them (e.g., input) instead relying on C++ virtual methods. I'm looking over the qtHaskell docs now (which is just a wall-o-type-signatures) and it appears to have some kind of setHandler function for these virtual functions. I have no idea how this is supposed to work. AFAIK qtHaskell is just a one-man project, so it's understandably less mature than Gtk2Hs, considering the huge impedance mismatch between functional/imperative Haskell and OO C++. As for wxWidgets, I have not used it, but as I understand it's mostly history. The Gtk2Hs team is large, active and contains many luminaries of the Haskell community, so that is where the action is at. Unfortunately though, it's Gtk+, so your "real world" better not have any Windows or Mac users in it.