Real time audio applications are top of my list of "crazy projects I would work on if I had a month spare". I think it might work out nicely. My approach wouldn't be to talk directly to audio hardware from Haskell but instead use a framework like Lava to generate low level code from an embedded DSL. I think that would be a really elegant way to work at a high level and yet have the result execute *faster* than traditionally written C++ code. -- Dan
On Tue, Nov 11, 2008 at 7:41 PM, sam lee <[EMAIL PROTECTED]> wrote: > I haven't found multitrack audio recording applications written in > Haskell. These are usually written in C++ using Jack audio or ASIO. > This probably means that it is not a good idea to write real time > audio applications in Haskell at the moment. > So, probably avoid writing applications that use a high frequency > timer and IO that should be synchronous to the timer in Haskell. > > On Tue, Nov 11, 2008 at 9:02 PM, wren ng thornton <[EMAIL PROTECTED]> wrote: >> Dave Tapley wrote: >>> >>> Hi everyone >>> >>> So I should clarify I'm not a troll and do "see the Haskell light". But >>> one thing I can never answer when preaching to others is "what does >>> Haskell not do well?" >>> >>> Usually I'll avoid then question and explain that it is a 'complete' >>> language and we do have more than enough libraries to make it useful and >>> productive. But I'd be keen to know if people have any anecdotes, >>> ideally ones which can subsequently be twisted into an argument for >>> Haskell ;) >> >> With the appropriate caveats about particular subdomains (see final >> paragraph), I wouldn't use Haskell for scripting. That is, (1) for >> Bash-style programming where 95% of the code is just invoking *nix jobs, or >> (2) for very simple yet regex-heavy scripts where Perl/Awk/Sed is often >> used. >> >> Re #1: Honestly, I don't see anything other than a dedicated competitor >> being able to unseat Bourne/Bash at this task. Certainly a competitor would >> have much room for improvement-- what with being able to replace >> string-rewriting semantics with term-rewriting semantics, vastly improving >> type safety and catching innumerable bugs. However, with unsavory frequency, >> it is exactly those type-unsafe substitutions which can make shell scripting >> cleaner and more direct than a type-safe alternative. Having type safety as >> well as this sort of non-compositional structure would take a good deal of >> work to get right. >> >> Re #2: People often complain about spooky Perl that uses things like >> implicit $_ or other hidden variables. While these constructs can make any >> sizable project unmaintainable, for the quick and dirty jobs they're just >> what's needed to get things done with clarity. While ByteString code using >> regexes is just as fast in Haskell, it's often more than twice as long as >> the Perl, Sed, or Awk equivalents because many of the basic control >> structures (like Perl's -n, -p, -l,... flags) aren't already provided. >> >> >> That said, this isn't necessarily a bad thing for Haskell. "Real" >> programming languages often don't do so well in these areas (Perl being the >> exception), and they don't feel too bad about it. Both varieties of shell >> scripting are very much of the DSL nature; for programs with a significant >> amount of "actual logic" instead of mere plumbing or regexing, Haskell can >> certainly outshine these competitors. On the one hand, C and friends fight >> dirty and much work has been done so Haskell can join in on the bit-bashing >> glory. However, shell scripting is a whole different kind of imperative muck >> and very little work (that I've seen) has tried to get Haskell to jump down >> in the sewers with them. >> >> -- >> Live well, >> ~wren >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
