What *not* to use Haskell for

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Jeff Heard
Kyle, I would say that most apps don't actually require that you write
a mutation heavy inner loop.   They can be written either way, and
Haskell gives you the facility to do both. Even my field, which is
visualization can be written either way.  I write with a mutation
heavy inner loop myself, because it's how I started out, and I haven't
had any trouble with performance.  OpenGL is always my upper bound.
Even 2D code, which I've written on occasion seems not to suffer.

On Tue, Nov 11, 2008 at 5:23 PM, Kyle Consalus <[hidden email]> wrote:

> On Tue, Nov 11, 2008 at 1:51 PM, Don Stewart <[hidden email]> wrote:
>> consalus:
>>> On Tue, Nov 11, 2008 at 2:38 AM, Dave Tapley <[hidden email]> 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 ;)
>>> >
>>> > Cheers,
>>> >
>>> > Dave
>>> >
>>> > _______________________________________________
>>> > Haskell-Cafe mailing list
>>> > [hidden email]
>>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> >
>>>
>>> I think some would disagree with me, but I would advise against using
>>> haskell for a task that necessarily requires a lot of mutable state
>>> and IO and for which serious performance is a big factor.  I'm not
>>> talking about stuff that can be approximated by zippers and whatnot,
>>> but rather situations where IORefs abound and data has identity.
>>> Haskell can quite capably do mutable state and IO, but if your task is
>>> all mutable state and IO, I'd lean toward a language that makes it
>>> easier (OCaml, perhaps).
>>
>> Do you have an example of a mutable state/ IO bound application, like,
>> hmm, a window manager or a revision control system or a file system...?
>>
>> -- Don
>>
>
> Of course, with a lot of skill, good design, and a pile of language
> extensions state/io-heavy
> Haskell code can be clean and flexible. Performance can be pretty
> good, and for complex algorithmic
> code arguably a better choice than most other languages. Still,
> neither of the projects you reference (to my knowledge)
> have a mutation-heavy inner computation loop. XMonad does all of its
> mutation in a custom monad that is ReaderT StateT IO or something
> similar, and it apparently works beautifully. However, my
> understanding is that stack of monad transformers tend not to be
> particularly efficient, and while that usually isn't an issue, the
> case that I'm talking about is that where mutation
> performance is a major concern.
> Other languages offer similar expressive power, minus the joys of
> laziness and referential transparency.
> Persistent data structures are great, but if you're not using the
> persistence it is less convenient and less efficient.
> So again, Haskell _can_ do mutation and IO just fine, but if laziness,
> purity, and immutability will be the rare exception
> rather than the rule, might be easier to use a language that makes
> strictness and impurity easier.
> (Unless you're a Haskell guru, in which case I imagine Haskell is
> always the most convenient language to use).
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



--
I try to take things like a crow; war and chaos don't always ruin a
picnic, they just mean you have to be careful what you swallow.

-- Jessica Edwards
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Go Haskell! (was: What *not* to use Haskell for)

Claus Reinke
In reply to this post by Don Stewart-2
> Do you have an example of a mutable state/ IO bound application, like,
> hmm, a window manager or a revision control system or a file system...?

If you're looking for a challenge, how about this one (there used to
be lots of Haskellers into this game, any of you still around?-):

http://computer-go.org/pipermail/computer-go/2008-October/016680.html

The specification is the numbered list at the end of the message, or in the
zip file with the Java example implementation (README). Actually, the
interesting part from a performance perspective doesn't even require GTP
or AMAF, just implement the random legal playouts for a 9x9 board, do
a loop over them, keeping some basic win/loose/game length statistics.

Can you complete that in competitive speed, preferably from the specs,
without just transliterating the low-level Java code?  I won't tell you yet
what typical playouts-per-second-per-core numbers are floating about
for "lightly" optimised code; try to improve your code and say "stop,
this is good enough" before comparing with the Java bot runtimes.

You'll probably have no room left for any high-level operations, ending
up with mostly imperatively threaded array manipulations in a loop that
is expected to be run several thousand times per real-game move (the
idea being to run lots of dumb, but legal, simulations to the end, where
evaluation is easy, gather statistics, then choose the move that seems
to have the most potential). Bonus points if you can preserve any of the
high-level advantages of working in Haskell (such as easy debuggability,
because there will be bugs, especially if you can't afford to maintain
redundant information representations) without sacrificing speed. (*)

As specified, the bot won't win any tournaments - it is the starting
point (or remote ancestor) for the current champions, with lots of room
for algorithmic improvement, not to mention actual game knowledge,
tree search and parallelization (the configurations being used for tournaments
and exhibition games are highly parallel). The reference spec is a recent
effort, meant to provide a first milestone for aspiring Go programmers
to compare their code against, while also inviting programmers to
to show how their favourite language is eminently suitable for Go
programming (without sacrificing performance!). There are versions
in Java, D, C++, C#, and C around somewhere, possibly others.

But: please, no language evangelism on that mailing list! Those people
seem decent, peaceful and open-minded (there's even a Haskell spec
of a simple rule set here http://homepages.cwi.nl/~tromp/go.html ).

And some of them have years (a few even decades) of experience,
much of which is made available in the mailinglist archives and
bibliography (pointers available on request - if you wanted to get
serious about playing with Go programming, you'd be expected
to mine the archives and bibliography, because just about anything
you'll come up with in your first few months will have been discussed
already;-), in spite of commercial interests and ongoing competitions.
They are already tired and wary of useless language wars (who isn't?).

Claus
    (who has been wanting to write a Go player ever since he
    had to decide between research and learning more Go, either
    one trying to eat all available time and then some; perhaps I
    should write a researcher instead, and return to playing Go?-)

(*) it would be nice if the sequential baseline performance of
    functional Haskell/Ghc arrays would be better, btw; that would
    make the ongoing work on parallel arrays much more interesting.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Arnar Birgisson
In reply to this post by Dave Tapley-2
Hi again,

On Tue, Nov 11, 2008 at 11:38, Dave Tapley <[hidden email]> wrote:
> 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?"

C does extremely well when you want to write low level exploits, such
as meddling with memory, the machine stack and others.

This goes also for writing device drivers, media codecs, compression
algorithms etc. and applications that are mostly about copying bits
(with some transformations) between various memory locations.

I imagine this kind of thing would be very hard to write in Haskell.

Does that count?

cheers,
Arnar
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

wren ng thornton
In reply to this post by Dave Tapley-2
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

sam lee
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 <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Jeremy Shaw-3
At Tue, 11 Nov 2008 22:41:48 -0500,
sam lee 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.

There are at least two Haskell bindings to JACK. I wrote one of
them. The big issue is (no surprise) garbage collection. Audio stuff
can generate a lot of garbage fast if you aren't careful. And the
stop-the-world collection can happen at unfortunate times.

The uvector library might help things -- but ultimately Haskell would
need a more realtime friendly garbage collector.

So, realtime audio can be done in Haskell today, but is is definitely
fragile at best.

- jeremy
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Eelco Lempsink-4
In reply to this post by Dave Tapley-2
On 11 nov 2008, at 11:38, Dave Tapley wrote:
> 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 ;)


Working with relational databases can be a bit cumbersome.  There's  
some bitrot in the HaskellDB packages in general, so taking a more low-
level approach seems sensible, but because the lack of extensible  
records you don't get much help from the compiler, so you need to do  
most of the checking (and 'marshalling') yourself.  In that sense,  
it's not worse than doing it with most other languages, except that  
for those languages there are often high-level libraries available to  
do, for example, cute things like object relational mapping (ORM).

--
Regards,

Eelco Lempsink


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

PGP.sig (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Ketil Malde-5
In reply to this post by Don Stewart-2
Don Stewart <[hidden email]> writes:

> Data.ByteString is full of mutation-heavy inner loops.

I suspect you are missing Kyle's point, which I interpret to be more
like what Paul Graham talks about in  "ANSI Common Lisp":

     [OO] provides a structured way to write spaghetti code. [...] For
     programs that would have ended up as spaghetti anyway, the object
     oriented model is good: they will at least be structured
     spaghetti.

In my opinion, Haskell is pretty bad at spaghetti.  And although it is
possible that some programs simply need to be spaghetti-structured, I
still think not supporting it is a good thing - Haskell should instead
provide the tools for writing an equivalent non-spaghettized program.

Bytestrings have mutation-heavy inner loops, but localized,
well-structured, and exporting a neat, pure interface, so they don't
count here.

> There's nothing magic about it.

Now you're just being modest.

-k
--
If I haven't seen further, it is by standing in the footprints of giants
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Malcolm Wallace
In reply to this post by Anatoly Yakovenko
"Anatoly Yakovenko" <[hidden email]> wrote:

> Has there been any progress in getting ghc set up for porting to non
> x86/unix/windows platforms?  Can it generate ropi code?  It would also
> be nice to be able to compile to C that rvct/arm tools can compile in
> thumb mode.

AFAIK, you can bootstrap ghc onto lots of non-PC-centric platforms,
using the unregisterized porting guide.  However, it is not a trivial
exercise, and it does not address the question of setting ghc up as a
cross-compiler, should your device be too small to host ghc at all.

Other Haskell compilers might be a better starting point.  For instance,
nhc98 uses portable C as a target language, and has a configure-time
option to set it up as a cross-compiler.  See
    http://www.cs.york.ac.uk/fp/nhc98/install.html
(cross-compiler info towards the bottom of the page).  The example
given is for ARM/linux.

Regards,
    Malcolm
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Reinier Lamers-2
In reply to this post by Dave Tapley-2
2008/11/11 Dave Tapley <[hidden email]>:
> 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?"

Let's say something controversial: I think that Haskell's type system
gets in your way when you're writing one-shot scripts that don't need
to conform to the highest correctness standards. Imagine typing a
command at the shell prompt and getting the sort of abstract error
message that Haskell compilers give every now and then, like:

> whyerror.lhs:36:25:
>     Ambiguous type variable `a' in the constraint:
>       `Arrow a' arising from use of `>>>' at whyerror.lhs:36:25-27
>     Possible cause: the monomorphism restriction applied to the
> following:
>       liftA2' :: forall b a1 b1 c. (a1 -> b1 -> c) -> a b a1 -> a b
> b1 -> a b c
>         (bound at whyerror.lhs:36:1)
>       unsplit' :: forall a1 b c. (a1 -> b -> c) -> a (a1, b) c
>         (bound at whyerror.lhs:34:1)
>       split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1)
>     Probable fix: give these definition(s) an explicit type signature
>                   or use -fno-monomorphism-restriction

You don't want to be bothered by such monstrosities (yes, they are,
even though many of you may not see it because of years of
conditioning) when you're just hacking up a simple script to make a
catalog of your MP3 collection / check for patterns in log files /
whatever.

Also, in my experience Haskell is not so good at data structures where
you can't do structural recursion easily, like graphs. In such cases
you want a language with easy pointers and destructive updates. You
can do those things in pure Haskell by using
the ST monad, but the code will be more verbose than in Java or C++,
and it will occasionally drive you insane with type messages like the
above (You thought you could use '$' freely instead of application?
Wrong!).

Regards,
Reinier
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Arnar Birgisson
Hi Reinier,

On Wed, Nov 12, 2008 at 14:22, Reinier Lamers <[hidden email]> wrote:
> Also, in my experience Haskell is not so good at data structures where
> you can't do structural recursion easily, like graphs. In such cases
> you want a language with easy pointers and destructive updates. You
> can do those things in pure Haskell by using
> the ST monad, but the code will be more verbose than in Java or C++,
> and it will occasionally drive you insane with type messages like the
> above (You thought you could use '$' freely instead of application?
> Wrong!).

Can you give examples of what you mean and why algebraic data types
are not sufficient? In my research most things are "structurally
recursive" and it was because Haskell is so good at such things that I
started using it.

cheers,
Arnar
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Don Stewart-2
In reply to this post by Reinier Lamers-2
tux_rocker:

> 2008/11/11 Dave Tapley <[hidden email]>:
> > 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?"
>
> Let's say something controversial: I think that Haskell's type system
> gets in your way when you're writing one-shot scripts that don't need
> to conform to the highest correctness standards. Imagine typing a
> command at the shell prompt and getting the sort of abstract error
> message that Haskell compilers give every now and then, like:
>
> > whyerror.lhs:36:25:
> >     Ambiguous type variable `a' in the constraint:
> >       `Arrow a' arising from use of `>>>' at whyerror.lhs:36:25-27
> >     Possible cause: the monomorphism restriction applied to the
> > following:
> >       liftA2' :: forall b a1 b1 c. (a1 -> b1 -> c) -> a b a1 -> a b
> > b1 -> a b c
> >         (bound at whyerror.lhs:36:1)
> >       unsplit' :: forall a1 b c. (a1 -> b -> c) -> a (a1, b) c
> >         (bound at whyerror.lhs:34:1)
> >       split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1)
> >     Probable fix: give these definition(s) an explicit type signature
> >                   or use -fno-monomorphism-restriction
>
> You don't want to be bothered by such monstrosities (yes, they are,
> even though many of you may not see it because of years of
> conditioning) when you're just hacking up a simple script to make a
> catalog of your MP3 collection / check for patterns in log files /
> whatever.

Why are you using Arrows in your one shot scripts? Do you use Arrows in
your shell scripts?

Seems like a strawman argument..

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Bugzilla from jonathanccast@fastmail.fm
On Wed, 2008-11-12 at 10:50 -0800, Don Stewart wrote:

> tux_rocker:
> > 2008/11/11 Dave Tapley <[hidden email]>:
> > > 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?"
> >
> > Let's say something controversial: I think that Haskell's type system
> > gets in your way when you're writing one-shot scripts that don't need
> > to conform to the highest correctness standards. Imagine typing a
> > command at the shell prompt and getting the sort of abstract error
> > message that Haskell compilers give every now and then, like:
> >
> > > whyerror.lhs:36:25:
> > >     Ambiguous type variable `a' in the constraint:
> > >       `Arrow a' arising from use of `>>>' at whyerror.lhs:36:25-27
> > >     Possible cause: the monomorphism restriction applied to the
> > > following:
> > >       liftA2' :: forall b a1 b1 c. (a1 -> b1 -> c) -> a b a1 -> a b
> > > b1 -> a b c
> > >         (bound at whyerror.lhs:36:1)
> > >       unsplit' :: forall a1 b c. (a1 -> b -> c) -> a (a1, b) c
> > >         (bound at whyerror.lhs:34:1)
> > >       split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1)
> > >     Probable fix: give these definition(s) an explicit type signature
> > >                   or use -fno-monomorphism-restriction
> >
> > You don't want to be bothered by such monstrosities (yes, they are,
> > even though many of you may not see it because of years of
> > conditioning) when you're just hacking up a simple script to make a
> > catalog of your MP3 collection / check for patterns in log files /
> > whatever.
>
> Why are you using Arrows in your one shot scripts?

Because a generic operator like (>>>) is

a) More likely to exist, and
b) easier to remember

than a special case operator like --- actually, I don't think GHC does
come with a standard version of (>>>) type-specialized to functions,
only a version of (<<<).  Or if it does, I can't remember it.

> Do you use Arrows in
> your shell scripts?

I use pipelines.  Frequently.  I even type them up at the command line.

Beyond that, I was considering the pipeline

uses -l snippet_calculate\\b |
perl -lne 'chomp; print $_ unless qx{svn st | grep $_}'

(`uses' is a recursive grep-like shell function I have).  The use of
perl immediately suggested that it could profitably be re-written in
Haskell (actually, in a similar FP language I've been designing --- not
relevant); my translation included a line something like

interactiveM $ filterM $ comp >>> \ x -> <translation of qx{svn st |
grep $x}>

So yeah, I use arrows in my shell scripts.  Who doesn't?

(On the other hand, I'm actively designing an FP shell-like language...)

jcc


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Stefan Monnier
In reply to this post by Dave Tapley-2
> 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?"

The most obvious cases where Haskell does not do well, for me:

- When you feed it Java code.  Incidentally, the same holds when you
  feed it C code.

- When you try to write a malloc library.


        Stefan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Andrew Coppin
In reply to this post by Dave Tapley-2
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 ;)
>  

Anything with hard performance requirements, and/or that needs to run on
tiny computational resources (CPU speed, RAM size, etc.)

I'd say "device drivers" too, except that the House guys apparently
managed to do this...

I'd really love to tell everybody that "Haskell is *the* language of
algorithms" - except that it tends to not be very performant.
Unfortunately, with the current state of the art, high-performance
computer programs still require lots of low-level details to be
explicitly managed. Hopefully one day this will cease to be the case.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Tom Hawkins-2
In reply to this post by Jules Bean
On Tue, Nov 11, 2008 at 5:18 AM, Jules Bean <[hidden email]> 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?"
>
> GHC's scheduler lacks any hard timeliness guarantees.
>
> Thus it's quite hard to use haskell in realtime or even soft-realtime
> environments.

Actually, Haskell is an excellent language for hard real-time
applications.  At Eaton we're using it for automotive powertrain
control.  Of course, the RTS is not running in the loop.  Instead, we
write in a DSL, which generates C code for our vehicle ECU.

Thanks to this great language, we traded 100K lines of Simulink for 3K
lines of Haskell.  Our current program is planned to hit the
production lines in a few months.

With similar methods, Haskell is also a great language for ASIC and FPGA design.

-Tom
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Don Stewart-2
In reply to this post by Andrew Coppin
andrewcoppin:

> >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 ;)
>
> Anything with hard performance requirements, and/or that needs to run on
> tiny computational resources (CPU speed, RAM size, etc.)
>
> I'd say "device drivers" too, except that the House guys apparently
> managed to do this...
>
> I'd really love to tell everybody that "Haskell is *the* language of
> algorithms" - except that it tends to not be very performant.

Depends on who's writing the Haskell in my experience.
GHC's a perfectly capable compiler if you feed it the proper diet.

-- Don (Board member of the "Don't think linked lists are the same as UArr Double" movement)
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: What *not* to use Haskell for

Malcolm Wallace
In reply to this post by Stefan Monnier
>>  "what does Haskell not do well?"
>
> - When you feed it Java code.  Incidentally, the same holds when you
>  feed it C code.


I've heard that Haskell's new (developed in this year's GSoC)  
Language.C libraries were able to parse millions of lines of C code  
from the Linux kernel, including many gcc extensions, without a single  
error.  That doesn't sound too shabby to me.

Regards,
     Malcolm

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

ajb@spamcop.net
In reply to this post by Tom Hawkins-2
G'day all.

Quoting Tom Hawkins <[hidden email]>:

> Actually, Haskell is an excellent language for hard real-time
> applications.  At Eaton we're using it for automotive powertrain
> control.  Of course, the RTS is not running in the loop.  Instead, we
> write in a DSL, which generates C code for our vehicle ECU.

Bingo!  And thanks for someone for admitting that they do this. :-)
"Hard real-time applications" is a huge area, and not all of the code
that you write is code that ends up running on the target.

Generally, in DSL/MDD-style development, not very much of the code that
you write ends up running on the target.  In some cases, _none_ of the
code you write ends up running on the target.  Haskell is almost ideal
for tasks like this.

Cheers,
Andrew Bromage
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: What *not* to use Haskell for

Lennart Augustsson
People have been admitting to using Haskell like that for quite a while now.
I think it's an excellent use of Haskell as a DSEL host.

  -- Lennart

On Thu, Nov 13, 2008 at 12:40 AM,  <[hidden email]> wrote:

> G'day all.
>
> Quoting Tom Hawkins <[hidden email]>:
>
>> Actually, Haskell is an excellent language for hard real-time
>> applications.  At Eaton we're using it for automotive powertrain
>> control.  Of course, the RTS is not running in the loop.  Instead, we
>> write in a DSL, which generates C code for our vehicle ECU.
>
> Bingo!  And thanks for someone for admitting that they do this. :-)
> "Hard real-time applications" is a huge area, and not all of the code
> that you write is code that ends up running on the target.
>
> Generally, in DSL/MDD-style development, not very much of the code that
> you write ends up running on the target.  In some cases, _none_ of the
> code you write ends up running on the target.  Haskell is almost ideal
> for tasks like this.
>
> Cheers,
> Andrew Bromage
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12345