Home » forums » LtU Forum

Haskell in the real world: writing a commercial program in Haskell

I thought this paper may be of some interest to LtU readers. By Curt J. Sampson, Starling Software:

I describe the initial attempt of experienced business software developers with minimal functional programming background to write a non-trivial, business-critical application entirely in Haskell. Some parts of the application domain are well suited to a mathematically-oriented language; others are more typically done in languages such as C++.

I discuss the advantages and difficulties of Haskell in these circumstances, with a particular focus on issues that commercial developers find important but that may receive less attention from the academic community.

I conclude that, while academic implementations of "advanced" programming languages arguably may lag somewhat behind implementations of commercial languages in certain ways important to businesses, this appears relatively easy to fix, and that the other advantages that they offer make them a good, albeit long-term, investment for companies where effective IT implementation can offer a crucial advantage to success.

Paper available here, slides from ICFP talk available here.

The "disadvantages" section seems interesting, as many of the disadvantages of Haskell as a commercially viable language (in Sampson's opinion) seem to stem from lack of decent tool support. However, a quick browse seems to confirm that many efforts are being made to address this (e.g. Hare, a Haskell refactorer, HLint, a lint equivalent, etc. etc.)

Are there any more examples of papers, discussing the pros and cons of functional languages in a commercial setting, like this one?

EDIT: fixed broken link to paper.

By dpmulligan at 2009-10-09 09:49 | LtU Forum | previous forum topic | next forum topic | other blogs | 12240 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Broken link

The link to the paper is broken--it just needs an "http://" on the front.

By John Stracke at Fri, 2009-10-09 12:46 | login or register to post comments

Fixed. Sorry about that!

Fixed. Sorry about that!

By dpmulligan at Fri, 2009-10-09 13:17 | login or register to post comments

Refactoring

Is the complaint of the authors about refactoring (p4-5) simply a complaint about strongly typed languages, or is there something more specific to Haskell that I am missing?

By Charles Stewart at Fri, 2009-10-09 13:50 | login or register to post comments

Mostly...

...it's the former, but there's a little of the latter as well.

In Haskell, all top level definitions are implicitly mutually recursive, and the compiler does a topological sort to figure out what the actual dependencies are. Contrast this with ML, where top level definitions are all lexically scoped, and recursive definitions need to be explicitly identified.

As a result, when you make a change, it can be a little tricky to determine which definitions are actually affected by the change -- so it can be tricky to figure out what the broken definitions you need to hide before testing are. In ML, the rule is: just hide everything after your change, and your module will typecheck (assuming your change does). I happen to prefer the ML style, but the Haskell style lends itself to structuring programs in top-down style (which many people who are not me do like).

Obviously, this issue could be entirely obviated by appropriate IDE support. It just doesn't happen to be, yet.

By neelk at Fri, 2009-10-09 15:23 | login or register to post comments

too much recursion

Hear hear. I really appreciate the fact that ML forces definitions to go "in order", and that recursion and mutual recursion must be explicitly marked as such. I think allowing mutual recursion all the time in an uncontrolled and unmarked way leads to code that is harder to reason about and harder to read than it should be.

By yminsky at Sat, 2009-10-10 00:37 | login or register to post comments

Tools

Basically if you go with java then your tools handle all the tedious refactoring stuff for you. Haskell lacks these tools so there is a good bit of grunt work if you want to Refactor in Haskell. It applies more to compiled languages since you can't do half a job, test, then fix up the rest.

By stonemetal at Sat, 2009-10-10 01:00 | login or register to post comments

Minsky

Are there any more examples of papers, discussing the pros and cons of functional languages in a commercial setting, like this one?

Yaron Minsky, Jane St. Capital, in The Monad.Reader Check the archives.

By Z-Bo at Fri, 2009-10-09 21:04 | login or register to post comments

A better reference

is probably the JFP paper, which you can find here. There's also a talk I gave at CMU on the same subject.

By yminsky at Sat, 2009-10-10 00:39 | login or register to post comments