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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
