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
