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
