[Haskell-cafe] Re: [Haskell-beginners] Accounting Engine in Haskell

[Max Cantor]

I think Haskell would be an excellent choice.  

Several reasons come to mind:

Given the arbitrary complexity of such projects, an EDSL describing book entries etc would be a very good fit for the project.  As people have said once or twice, Haskell is a great fit for EDSLs
 
If you want to get ambitious and scale this up to a multithreaded, multiuser environment, STM would be a very good concurrency model.  This pretty much just leaves Haskell or Clojure.

Finally, the type system of haskell is hugely useful to this project.  Jane Street Capital (ocaml users and damned good at it) has a programming motto: make illegal transactions unrepresentative.  The type systems of Haskell and OCaml let you structure this kind of project in a way to catch most of your bugs at compile time.

So, I think Haskell is the perfect intersection of EDSL support, Concurrency, and powerful, static typing for the project.

Good luck, keep us informed of your progress.

Max
 

On Jun 15, 2010, at 5:34 PM, Yitzchak Gale wrote:

> Hi Amir,
> 
> Amiruddin Nagri wrote:
>> My current project is about making an accounting engine...
> 
> Take a look at the related but different project "hledger".
> 
> http://hackage.haskell.org/package/hledger
> http://hackage.haskell.org/package/hledger-lib
> 
>> consistency, handling large data(performance) and
>> availability...
>> I am interested in knowing if Haskell will be the right fit
>> for my project.
> 
> These things can certainly be achieved, and Haskell is
> a great platform for it. Reliability and assurance of correctness
> are very important for financial systems, and Haskell is
> especially good at providing them together with good
> performance.
> 
> However, keep in mind that you are undertaking a very
> ambitious project. There are a lot of little design decisions
> to be made along the way which, if made without a lot of
> previous experience in whatever language you are using,
> could lead to serious problems later on in a large system
> like this.
> 
> I recommend:
> 
> o Start with a less ambitious version of the project -
>  a simpler prototype with less requirements, or components
>  that can be developed as a stand-alone and later integrated
>  into your larger system.
> 
> o Work closely with the community, on the #haskell
>  IRC channel and the Haskell Cafe mailing list, to get
>  guidance from experienced Haskellers. Share and discuss
>  your code as you go along.
> 
> (Or, if you select a different language that you are not
> very experienced in for developing large high-assurance
> commercial systems, do the same with that language's
> community.)
> 
>> Also there has been some concerns because of lazy evaluation
>> in Haskell and memory leaks associated with it.
> 
> The possibility for memory and performance leaks in large
> systems written in Haskell is no more or less than in any
> other mature programming language. As in any language,
> it takes experience and care to avoid them as your application
> scales up.
> 
> Good luck,
> Yitz
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe