[Haskell-cafe] What *not* to use Haskell for

[Dan Piponi]

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 <skynare at gmail.com> 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 <wren at freegeek.org> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>