[Haskell-cafe] Are you using Haskell on the job?

[John Goerzen]

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