
On Mon, 2004-05-03 at 16:52, mikeb@manor.org wrote:
The toy application I've "designed" for myself is a simple GUI-based app that can load a Sun .au format sound file, display its waveform in a window, perform some simple filtering, play the sound for the user, and then save the changed sound file back out to disk. If I get familiar enough with the respective environments I'd like to add zooming in/out and scrolling to the waveform display.
Here's my positive experience with GUI programming in Haskell; I've been hacking on gtk2hs recently - the Haskell bindings for Gtk+ 2.x. Yesterday I wrote toy program as a demo. It's a viewer for GHC's timing profile log files. It parses a log file, populates a tree view with the data and allows you to vary a cut-off threshold on the data. It took about 4hrs to write and comes to less than 250 lines of code in two modules. The parsing is a bit slow (15sec to parse >850k log) because I used my patented zero-optimisation(tm) technique. :-) There are plenty of not-too difficult techniques for making the parsing go faster if you care about performance. (eg use a lexer and parsec or happy) If I were going to try and do your toy app I'd consider these things: Haskell's standard IO facilities are primarily text-oriented and designed for convenience rather than performance. If performance is important I'd look at some of GHC's low-level IO facilities: http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC.IO.html#v%3As... Eg load the whole file into memory and then use the marshaling facilities of Haskell's FFI to read the records out of your file. (I'm guessing here that .au files are basically a binary file with a header followed by an array of records) For playing a sound file either pipe it to an external command line player utility - see POpen for this, or you'll have to bind to some existing C library that plays .au files. This would be harder (ie take longer) but doable, see hsc2hs or c2hs for preprocessors that help with creating bindings for C libraries. For the GUI I'd obviously recommend Gtk+ and gtk2hs. If you need a cross-patform GUI, there's wxHaskell - which also has a nicer mid-level wrapper library at the moment. gtk2hs will allow you to use Glade which makes designing the GUI much easier and quicker. For the waveform display you can either draw directly into a DrawWindow or draw into a Pixmap (an off-screen buffer) and then display the pixmap in a DrawWindow or GtkImage widget.
This application should allow me to see all kinds of different characteristics of the language/implementation, such as performance (how fast can the filter run), I/O (how fast can I load/save data to disk), OS interaction (how easy can I "play" the audio), user acceptance (how easy is it to do GUI programming) and of course the software engineering goals of modularity, correctness, and simplicity.
I'd say that modularity, correctness, and simplicity are Haskell's strengths while low-level high performance bit shifting is not. No doubt, Haskell would allow you to build elegant type-safe abstractions for dealing with large binary files, but that's an investment that's hard to justify for a prototype and getting good performance would require careful thought. Duncan