appropriateness of haskell for GUIs
Hello, I'm totally new to Haskell. I'm thinking of using it for a personal project, which is a gui-based musical score editor. (*) Why Haskell? I've always been interested in proving my software's correctness, usually in practical and informal sense. In other words, I would like to reduce bugs by having a really good understanding of what my software does. I also just want to learn Haskell. Before I invest a lot of time in learning Haskell, however, I want to understand if it's the right language for doing a gui-based musical score editor. First of all, I need a gui toolkit of some sort, and I notice that bindings to Qt exist. I'm already very familiar with Qt, so that's good. I also need to access the Windows midi api, and I see there is a module called hmidi. However, a gui program is essentially event driven and heavily interacts with the outside world. I don't know how compatible these ideas are with Haskell. If I don't use Haskell, I will probably use Python, which I already know well. So basically the question is: Haskell or Python? Note: I would enjoy learning Haskell, so this is not a question of which language is better in an absolute sense... if Haskell is suitable, but not the best choice, I will still probably use it. Thanks, Mike (*) For those who ask why I'm doing my own music score editor when many already exist, it's because it needs to be integrated with my own computer-assisted composition system. As an editor, it will be primitive: that's not its main purpose.
Michael P Mossey wrote:
Hello, I'm totally new to Haskell. I'm thinking of using it for a personal project, which is a gui-based musical score editor. (*) Why Haskell? I've always been interested in proving my software's correctness, usually in practical and informal sense. In other words, I would like to reduce bugs by having a really good understanding of what my software does. I also just want to learn Haskell.
Before I invest a lot of time in learning Haskell, however, I want to understand if it's the right language for doing a gui-based musical score editor. First of all, I need a gui toolkit of some sort, and I notice that bindings to Qt exist. I'm already very familiar with Qt, so that's good. I also need to access the Windows midi api, and I see there is a module called hmidi.
However, a gui program is essentially event driven and heavily interacts with the outside world. I don't know how compatible these ideas are with Haskell.
If I don't use Haskell, I will probably use Python, which I already know well. So basically the question is: Haskell or Python? Note: I would enjoy learning Haskell, so this is not a question of which language is better in an absolute sense... if Haskell is suitable, but not the best choice, I will still probably use it.
Thanks, Mike
(*) For those who ask why I'm doing my own music score editor when many already exist, it's because it needs to be integrated with my own computer-assisted composition system. As an editor, it will be primitive: that's not its main purpose. _______________________________________________ Hi Michael - I'm also new to Haskell. Although I can't really give a definitive answer as to whether Haskell is appropriate for GUIs, I can mention several GUI libraries that exist for Haskell. They are wxHaskell, Gtk2Hs and qtHaskell. The following page mentions those and a number of others - http://www.haskell.org/haskellwiki/Applications_and_libraries/GUI_libraries
Note - that page says that "there is no standard (GUI lib) and all are more or less incomplete." Don't be too put off by that - from what I've seen, although I haven't used them myself, both wxHaskell and Gtk2HS now seem to be quite complete. I can't really comment on qtHaskell as I haven't seen that in action. - Hope this helps.... - Andy
On 21 Mar 2009, at 00:16, Michael P Mossey wrote:
Hello, I'm totally new to Haskell. I'm thinking of using it for a personal project, which is a gui-based musical score editor. (*) Why Haskell? I've always been interested in proving my software's correctness, usually in practical and informal sense. In other words, I would like to reduce bugs by having a really good understanding of what my software does. I also just want to learn Haskell.
Before I invest a lot of time in learning Haskell, however, I want to understand if it's the right language for doing a gui-based musical score editor. First of all, I need a gui toolkit of some sort, and I notice that bindings to Qt exist. I'm already very familiar with Qt, so that's good. I also need to access the Windows midi api, and I see there is a module called hmidi.
However, a gui program is essentially event driven and heavily interacts with the outside world. I don't know how compatible these ideas are with Haskell.
If I don't use Haskell, I will probably use Python, which I already know well. So basically the question is: Haskell or Python? Note: I would enjoy learning Haskell, so this is not a question of which language is better in an absolute sense... if Haskell is suitable, but not the best choice, I will still probably use it.
The rough situation of GUI programming on Haskell is that it works just as well as in any imperative programming language. This is rather disappointing, simply because so many other things are massively easier in Haskell, and this isn't true of GUI programming (yet). There are various efforts to write more functional GUI environments (Grapefruit, reactive, yampa, etc), but none are yet {stable | mature | scalable | some other reason} enough to use in production. Bob
Thomas Davie wrote:
On 21 Mar 2009, at 00:16, Michael P Mossey wrote:
Hello, I'm totally new to Haskell. I'm thinking of using it for a personal project, which is a gui-based musical score editor.
The rough situation of GUI programming on Haskell is that it works just as well as in any imperative programming language. This is rather disappointing, simply because so many other things are massively easier in Haskell, and this isn't true of GUI programming (yet).
Hi Bob, 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? 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. Thanks, Mike
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
participants (5)
-
Andy Elvey -
Michael Mossey -
Michael P Mossey
-
Peter Verswyvelen -
Thomas Davie