Re: [Haskell-cafe] Accounting Engine in Haskell
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Accounting Engine in Haskell
On Wed, Jun 23, 2010 at 2:30 PM, Paul Johnson p...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Accounting Engine in Haskell
My current project is about making an accounting engine that handles all the journal entries, transactions, portfolios etc. The communication with the engine is based on simple protocol, the things to be taken care of in the order are consistency, handling large data(performance) and availability. I came across a video lecture by Simon Peyton Jones where he gives an example from Financial domain (derivatives etc) to explain how haskell is being used and the advantages provided. I am interested in knowing if Haskell will be the right fit for my project. My requirements are transactional nature, which I believe is one of the strengths of functional programming, also handling large data set and being available. there is no such requirement for partitioning of data and the application is going to be centrally hosted on a single server. AFAIK OCaml and other functional languages are heavily used in financial domain, some of the reason are same as features I am looking for. 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 Also, if you have any suggestions of the choice of programming language, we have been looking into other functional languages like Scala and Clojure. But we have not dig deep on the performance aspects of these languages, if someone can shed a light on the pros- cons of these languages, it will help us very much to come to a decision. -Regards, Amir ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
