[Haskell] Re: [Haskell-cafe] Re: Hypothetical Haskell job in New York

[John Goerzen]

On Fri, Jan 09, 2009 at 01:06:44PM +0100, Manlio Perillo wrote:
> John Goerzen ha scritto:
>> On Thu, Jan 08, 2009 at 09:46:36PM +0100, Manlio Perillo wrote:
>>> I'm speaking about servers, not clients.
>>>
>>> How much of pure Haskell internet servers are used in a production   
>>> environment, in the "open internet" (and not in restricted LANs)?
>>
>> Does that really matter?  I tend to judge technology based on its
>> merits for my work, not on who uses it.  
>
> Well, testing a server is not easy.
> You can have a server that works for you without problems, but in  
> different environment it gives problems.

I completely understand that, as a sysadmin that has to maintain
mission-critical systems.  Unfortunately, it's also so often used as a
justification for using "whatever everyone else has".  So many people
buy Exchange for that reason, as an example.  Exchange has a pretty
long history of bugs that make it really unsuitable for use in the
Enterprise, yet people use it anyway because they think everyone uses
it.

A particularly amusing example is at
http://software.complete.org/software/issues/show/114 - my little
OfflineIMAP program appears to be able to take down entire Exchange
databases and force a restore from backup, because Exchange has a
hard-coded limit of 32k different mail header names *per
installation*, and OfflineIMAP generates one unique header each time
it uploads a message to the server.  If my program can do that
accidentally, imagine what someone with a will to do that could do.

Nobody would have ever tried Haskell, Python, or Perl in
mission-critical situations if they always thought like that.
Somebody has to be first, and I see no problem with it being us, as
long as we are confident of the outcome.

Part of the calculus has to be:

1) Can we test it under stress?

2) How confident are we that it will behave right under conditions we
can't test?  (Esp. malicious ones)

3) Can we fix it ourselves if it breaks?  How many others can fix it?

I really like Haskell because of #2.  While there is no 100%
guarantee, I feel better about Haskell not throwing a type error in
some obscure condition than I do about Python not doing so.  I also
like #2 because of the availability of both HUnit and QuickCheck.
Write your code right, and you can QuickCheck a significant part of
it.

-- John