On Wed, 5 May 2004, Frank Atanassow wrote:

Frankly, I think it's completely unrealistic to expect to be able to fairly evaluate Haskell in 32 hours. As you noted yourself, Scheme and Erlang, being strict, are much closer to conventional programming languages than Haskell is, so it's easier to transfer skills to them.

Yeah, I'm starting to see the difficulty in recommending a language I can barely dabble in up the chain (not as bad as pointy hair bosses, but still not computer scientists).

Furthermore, they're untyped, and learning how to exploit Haskell's static typing is one of the bigger hurdles to learning how to exploit Haskell.

That was one of the things that attracted me to Haskell...the type system. I enjoyed strong typing in ML when I played with it in college.

At best, I imagine you'll come away curious and hungry for more; but clearly that doesn't suffice for a "language evaluation".

Certainly.

Of course, the fact that Haskell can't be grasped in a day (or week) can be construed as a practical argument against its adoption. On the other hand, if you accept that there's no such thing as a free lunch, you might consider that a merit; what is the point of adopting a new language if it doesn't change the way you think about programming, and let you write old programs in new, perhaps better, ways? [1]

This is the crux of the argument. I don't understand how we can make good programming languages more popular. My son was born just a couple of weeks ago, and I barely have enough time now to keep up with anything in my career/field; I was lucky I convinced my management to let me do a (too-) brief language survey. But without having "thought" in Haskell for at least a couple of months, how can I hope to promote it successfully? How can I get a couple of months proficiency in Haskell unless I've promoted it successfully? (Co-routines? =)

While Haskell is IMO the best programming language around, and I want to encourage its broader adoption, if you want a well-designed language with good implementation and support which permits swifter skill transfer, may I (strongly) recommend you add Objective Caml to your list of candidates? Once you acquire some experience with an ML-like language such as OCaml, which after all resembles Haskell in many ways, you will, I believe, find yourself better equipped to evaluate Haskell.

Thanks for this...I actually just added ocaml to my list last night. I was looking over the "programming languages shootout" and read some of the source. It looks pretty neat. I spent last night writing a simple object system from scratch in Scheme with macros, and starting thinking about all the things I'd have to do to implement any kind of type safety, and it just sort of clicked that ocaml might be an interesting solution. Thanks again for your comments (and everyone's). -- Mike J. Bell This is all just my opinion. "Outside of a dog, a book is man's best friend. Inside it's too dark to read." mikeb@manor.org

On May 6, 2004, at 6:59 PM, S. Alexander Jacobson wrote:

I think someone wrote a book about multi-media apps in Haskell (I've seen a chapter somewhere from Conal Elliot) but I don't remember what it was.

Probably Paul Hudak's "The Haskell School of Expression". http://www.haskell.org/soe/ I had forgotten about this; maybe the soundwave GUI app idea is not so unrealistic? I haven't read SOE, but my impression is that it comes with a simple graphics library, and an on-topic book might get a novice up to speed quickly. Regards, Frank

It could be fun to figure out ways of writing jack-clients and plugins in Haskell. Would it be difficult, or stupid? Are callbacks to Haskell from C a problem?

Callbacks to Haskell are very easy using the ffi extension supported by Hugs, GHC and NHC. If components are standalone apps, that's all you need to do. If components are more like libraries, you'll need to take care of initializing the Haskell runtime, etc. (The ffi has calls to do this though I think only GHC implements them.)

I suppose an interesting jackable component written in Haskell would of necessity something more midi than audio oriented.

Because of raw performance or GC delays? 1) Performance If you take just a little care, GHC can generate some pretty fast code and generating 88 thousand samples per second (i.e., CD-rate stereo) isn't really that much on your typical PC hardware. Or, if you want to be able to use Hugs or GHC just isn't fast enough, you could write the inner loop in C and use Haskell to control how it is invoked. (I'm assuming that most audio ops can be expressed in terms of a few generic convolution operators.) We had good luck with this sort of approach at Yale when doing real-time visual tracking. (The important things to know about visual tracking are that you process megabytes of data per second and the more frames per second you can process the more reliable the tracking.) The 'inner loop' was written in C or hand-bummed assembly code and the rest was written in Haskell. Performance was something like 99.9% of equivalent C code. 2) GC delays. GC systems are usually tuned to minimise overhead but can usually be persuaded to minimise the average or worst delay by specifying different sizes of different allocation arenas and explicitly invoking the garbage collector. Again, this is something we did at Yale with the visual tracking. You'd probably do very well with a simple policy like invoking the GC N-times per second of sound processed. -- Alastair Reid

On Fri, 7 May 2004, Claus Reinke wrote:

for graphics, we've got OpenGL, and a nice Haskell binding to it, so I wonder whether there's a similar option for sound? e.g., does anyone have experience with PortAudio/PortMusic/PortMidi?

Looking over the PortAudio specs it's good for a software processing environment but not a lot of use to eg a game. OpenAL appears to be much the other way round. -- flippa@flippac.org

Claus Reinke wrote:

The thing that always confused me about OpenAL (www.openal.org) is the following part of the spec: [...]

The basic ideas behind OpenAL are quite easy and centered around 3 concepts: * Buffers containing (normally mono) audio data, which can be shared by sources (see below). This is where you put e.g. your WAV data. * Sources generating (perhaps directed) sound at a point in 3D space for the queues of buffers attached to them. These correspond to sound emitting entities in your virtual 3D world, e.g. enemies shooting at you. :-) * A single listener (= you) positioned at a point in 3D space. OpenAL renders the sound to your audio device (stereo headphones, 5.1 speakers, etc.) via a lower device layer (ALSA, DirectSound, etc.). It doesn't handle MIDI, but there are e.g. extensions for microphone input. The "spirit" of OpenAL is very much like OpenGL, and both fit quite nicely together, although you can use each of these libraries on their own. It works on all major platforms (WinDoze, Linux, MacOS X, ...) and is an "industrial-strength" library, meaning that even people who make their living from programming use it, see e.g. Unreal Tournament 2004 and quite a few other commercial games. A few months ago I started an OpenAL binding for Haskell, see the fptools repository at fptools/libraries/OpenAL. The basic functionality is there, but the binding is not complete yet. The main reason for the latter is that I couldn't get my 4.1 speakers working under my previous SuSE Linux, but I've just upgraded, so hopefully things have improved and the binding can be finished. Apart from that, having a binding for SDL would be nice, too, and somebody is already working on it, IIRC. Cheers, S.

On Saturday 08 May 2004 13:16, Sven Panne wrote:

Apart from that, having a binding for SDL would be nice, too, and somebody is already working on it, IIRC.

I would like to try these bindings. V.