7 Nov
2004
7 Nov
'04
1:50 p.m.
On Saturday 06 November 2004 05:49 pm, Peter Simons wrote:
> Since I have been experimenting with Arrows quite a bit just
> recently, I feel compelled to add something to the
> discussion.
>
> I too think that Arrow are a beautifully simple and elegant
> concept. However, once you write production code, you notice
> quickly that there is a significant difference between a
> code snippet that's been chosen specifically to illustrate
> the beauty of Arrows and something else.
>
> In my (albeit limited) experience, Arrows are not the answer
> "to it all" any more than any other clever software design
> technique is. The moment you need to do things like "apply"
> an Arrow, you are squarely in the domain of Monads again. So
> why not write a Monad to begin with?
>
> Plus, powerful abstractions that make the code look simple
> and elegant _always_ come at a price. An Arrow-based stream
> processor that performs the same task as my monadic BlockIO
> library does, for instance, results in a module that has
> half the size the StateT version does. Which is cool. But it
> is, as of now, also 10 times slower than the monadic version
> is. Which is not cool at all.
>
> It is quite likely that I don't understand Arrows well
> enough yet to get certain tasks done efficiently with them.
> But so far my impression is that they are great for certain
> tasks and not so great for other tasks. Which doesn't really
> come as a surprise. "One size fits all" doesn't seem to
> exist in the real world.
>
> Peter
Hi Peter - thanks for this -
It's really good to hear from someone who has used arrows, and you've done
a great job of describing their pros and cons too. ( Ouch - a module running
ten times slower than a monadic version - that's a real performance
hit ... :-)
Anyway - time for me to get into some "pottering around" to become more
familiar with Haskell and what it can do.... Bye for now!
- Andy