Kirk Martinez wrote:

Hello, fellow Haskell hackers! I am writing a term paper on Haskell in Business, and while I have gathered a lot of good information on the

I do hope you will publish your results somewhere.

* What were the pros and cons you considered when choosing a language? Why FP? Why Haskell?

Haskell's static type checking plus type inference were a big win. Java is so heavy-handed with its type system (yet not actually achieving real safety; see NullPointerException and ClassCastException) that is is a significant hindrance to productivity. Python is an agile language to write in, but things can sometimes blow up in your face long after you thought they were stable. Type inference is a killer feature in my book. Killer feature #2 is purity. It is just a really... freeing experience. I worry less about my Haskell code than I did about my Python code.

* What aspects of your problem domain were most critical to making that choice?

The need for stability of code in production.

* How has using Haskell given you a competitive advantage?

It has been, on more than one occasion, faster to write both an application and a library in Haskell that it would have been to write just the application in some other language. FFI also plays into that, thanks to some dinosaur proprietary software. But in the long run, our Haskell code is *solid*. OK, so there are occasional read-generated exceptions, but knowing to avoid that particular pitfall is easy and not burdensome. Bottom line: it is fast to write, and it works well.

* How is the software development lifecycle positively/negatively affected by using Haskell as opposed to a different language?

Compared to Python, my Haskell code is more likely to work when it manages to compile, and less likely to discover some weird type error after already going into production. Shorter development lifecycle there. Shorter testing cycle, and less hacking once it's in production. Back when we had AIX on-site, the benefit was not as clear. AIX was not well-supported by GHC, and I had to invest a non-trivial amount of time maintaining it there. OTOH, I had to invest a non-trivial amount of time just maintaining gcc and binutils there as well, so pick your poison I guess. Python worked pretty much out of the box on AIX.

* How did you convince management to go with a functional approach?

I am management. It never came up :-)

* Was the relative scarcity of Haskell programmers a problem? If so, how was it managed?

Yes and no. I don't hire people because they know $LANGUAGE. I hire people that are adaptable and love to learn new things. Finding time for them to learn Haskell has been an issue, and we haven't done it yet. On the other hand, they already maintain their own GHC development environments, and when I've been at conferences, they've successfully done a small bit of Haskell hacking for urgent problems. I am not concerned about them being able to learn Haskell, or about finding people with that ability. I'm somewhat concerned about us finding the time to permit them to do so though.

* Would you choose to use Haskell again for a similar project given what you know now?

Absolutely. Though I would not use WASH or HSQL again.

The best responses will not simply list answers, but also provide background and a bit of narrative on the project and insights gained. Feel free to reply to the list, or just to me personally if you prefer.

I have used Haskell for quite a few integration projects: data from vendor X has to go into a database from an app by vendor Y, and vice-versa. There is a lot of parsing, a lot of formatting, and a lot of database interactions and data validation. It is "messy": sometimes we get data in a format it shouldn't be in, sometimes we get errors, and we have to deal with this. One of my coworkers instinctively reaches for Perl for this, and I instinctively reach for Haskell. They both seem to work pretty well for it -- I think Haskell with Parsec works better than Perl, actually, thanks to its helpful error messages. Haskell was also at the heart of a system that we (a lawn mower manufacturer) pushed out to our dealers, letting them register the warranty on units they've sold and request rebates on a private website. This project requires data validation in several disparate systems and complex business rules governing eligibility and penalties for late submission. This was initially written using WASH, but rewritten to FastCGI plus a custom utility module. It also initially used HSQL, but I wrote HDBC mainly due to bugs and deficiencies in HSQL for this particular project. One database involved is a dinosaur proprietary system that supports ODBC but not unixODBC and is about 7 years out of date. We maintain a private branch of HDBC-ODBC to get it to compile with this. No language binding worked with it out of the box. Haskell was also a small part of our Linux on the Desktop initiative, in which we pushed out Linux as our standard corporate desktop to a large part of the company: about 60 office machines, plus quite a few data collection terminals in our manufacturing areas. One of the issues we faced was dealing with existing essential proprietary software that requires Windows. We set up a Windows terminal server and use rdesktop with SeamlessRDP to connect to it. But the problem arises: if you are using some Windows app that generates a spreadsheet, we want it to open with the OpenOffice on your local Linux box, not something running on the terminal server. I wrote a client/server app that contains a Linux-based server that runs on the PCs and a Windows-base client. We associate certain extensions with the Windows-based client, so if you open, say, a CSV file on Windows, it executes my little app, which connects to the Linux PC, sends the data over the network, and causes OpenOffice to open it locally. Both pieces of this were written in Haskell, and developed mostly on my Linux workstation. I installed GHC in a virtual Windows box, compiled the Windows version there, and it worked well. The cross-platform capability was nice. Haskell has become my "go to" language for anything involving CSV files and databases, a situation which is sadly quite common. I have been known to whip up quick scripts for a few users that import well-formatted CSV files into database tables in certain ways. Since they all have GHC on their (Linux) machines, I can plonk it down with source and #!/usr/bin/runghc in ~/bin, put a .desktop file in ~/Desktop for them, and they can drag a file to it to get it imported. Quick and easy. Hope that helps. -- John