[Haskell-cafe] Accounting Engine in Haskell

[Jason Dagit]

On Wed, Jun 23, 2010 at 2:30 PM, Paul Johnson <paul at cogito.org.uk> wrote:

> On 15/06/10 09:08, Amiruddin Nagri wrote:
>
>>
>> I wanted some insight as to how Haskell is going to help me with my
>> project. Also there has been some concerns because of lazy evaluation in
>> Haskell and memory leaks associated with it.
>> http://jlouisramblings.blogspot.com/2010/04/haskell-vs-erlang-for-bittorent-clients.html
>>
>>
> In this talk:
>
> http://www.galois.com/blog/2009/04/27/engineering-large-projects-in-haskell-a-decade-of-fp-at-galois/
> Don Stewart says that memory leaks are a tractable problem.  Just profile
> and look for the retainers.
>
> Lazy evaluation is a big win for large projects because it lets you
> modularise your solution; one function generates a data structure, and
> another function (or several) consume it.  If the data structure is big or
> infinite then conventional languages force you to either interleave the
> generator and consumer, or else jump through lots of hoops re-inventing lazy
> evaluation on a case-by-case basis.  With Haskell you just say what you mean
> and let the compiler worry about implementing it.


I think there are times when, in Haskell, you end up jumping through hoops
to get specific performance characteristics (iteratees for example), but it
appears to be the exception.  Usually evaluation on demand gives you what
you want and typically adding strictness in a few places fixes any
leakiness.  So, while Haskell is not perfect it gives you what you want more
often than not.  This translate directly into productivity gains.  It also
means that programmers tend to be happier using Haskell as they are fighting
the notation less.  Happy and productive is a win, even if you have to have
a period of optimization at the end of the release cycle.  I'd rather
optimize correct code than start with a fast buggy version.

I think at this point, the biggest weakness is that the tools for ensuring
properties about space and time usage are far less mature than our tools for
ensuring correctness.  How would you formally specify your space or other
performance needs?  On the other hand, our profiling tools are quite good
(ghc heap profiler, threadscope, criterion, etc) so as Don says, the problem
is tractable.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100623/ce3bfb38/attachment.html