On 8/8/07, Brian Hulley <[EMAIL PROTECTED]> wrote: > > In contrast, all the pure functional GUIs that I've seen are just > wrappers around someone else's imperative code, and moreover, they > exchange the simplicity of the object oriented imperative API for a > veritable mindstorm of unbelievably heavy, clunky, slow, inefficient, > inextensible, hard to understand encodings that seem to me to have the > effect of turning a high level language into some kind of circuit board > (I'm thinking of arrows etc). > > In defense of Haskell (wow!), note that imperative languages are not without problems in GUIs. In a multithreaded environment, typically only one thread is allowed to manage the GUI, and then you typically need to set up some sort of message-passing system to communicate between this thread and the others AFAIK? This is a total PITA, so if someone has a solution for this that would rock :-)
Question: to what extent do the Haskell wrappers around gtk and wxWidgets suffer from this problem? I mean, I havent tried them, so it's a genuine question. (Note: off the top of my head, in an imperative language, I guess one could use some sort of generator to take an interface and generate the message classes, and marshalling classes automatically) (Disclaimer: I havent really searched very hard for ways to handle threading in GUIs in imperative languages, since mostly I either use web pages as the visual interface, which avoids around the problem, or use a single thread, which also avoids the problem)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
