appropriateness of haskell for GUIs

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

appropriateness of haskell for GUIs

Michael Mossey
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.
Reply | Threaded
Open this post in threaded view
|

appropriateness of haskell for GUIs

Andy Elvey
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

Reply | Threaded
Open this post in threaded view
|

appropriateness of haskell for GUIs

Thomas Davie
In reply to this post by Michael Mossey

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
Reply | Threaded
Open this post in threaded view
|

appropriateness of haskell for GUIs

Michael Mossey


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


Reply | Threaded
Open this post in threaded view
|

appropriateness of haskell for GUIs

Peter Verswyvelen-2
On Sat, Mar 21, 2009 at 1:30 PM, Michael Mossey <[hidden email]>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