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

sam lee skynare at gmail.com
Tue Nov 11 22:41:48 EST 2008

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

More information about the Haskell-Cafe mailing list