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

[Thomas Hartman]

I've been using HSH with good results for sysadmin tasks, and recently
uploaded HSHHelpers to hackage.

Of course with Cpan a lot of stuff has already been done for you, but
that's a library issue.

Nothing beats bash for a quicky of course, but there a lot of ways to
shoot yourself in the foot (eg global variables, hard to remember
quoting rules) that haskell protects me from. Like perl protects you,
but better.

thomas.

2008/11/12 wren ng thornton <wren at freegeek.org>:
> 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
>