[Haskell] Haskell as a disruptive technology?

[Paul Johnson]

Neil Mitchell wrote:

>>> - Larger memory footprint
>  
>
> You are talking about GHC, not Haskell. Take a look at nhc98, which
> has a small memory footprint.

I don't want to get into a compiler flame war.  The fact is that if you want to do huge datasets or very fast computation (the two tend to go together) then Haskell is the wrong language.  This isn't an attack on Haskell, its a straightforward look at the strengths and weaknesses of the language.

>> - Little integration with GUI tools.  No "Visual Haskell" or "Borland
>> Haskell" equivalents.
>  
>
> http://www.haskell.org/visualhaskell/ - indeed there is  :) 

I've never used Visual Haskell, but from the web page two things stand out:

1: Its version 0.0.  This is not for production use.

2: Its just a programming environment.  The point I was making was about integration with GUI tools.  You can't (AFAIK) draw a dialog box and then tie each button to a Haskell function in the IO monad.

>> - Little integration with databases.
>  
>
> There are quite a few Haskell DB programs, I've never used any, but
> they do exist.

I have used HSQL, and it does what it does perfectly competently.  But 
it requires a bunch of boilerplate code in the IO monad for every 
query.  There are higher level libraries that build nice type-safe stuff 
on top of this, but they don't seem to be production strength yet.

Remember that this is not about what Haskell could or should be in the 
future, its about what Haskell is right now.  If you start a Haskell 
development project then this is the reality that you face.

Now, we could try to fix these "deficiencies".  That means playing 
catch-up with the entire infrastructure that has been erected around 
conventional languages.  We will simply never succeed.  Sure, we can 
probably do it with a 10th the manpower of the conventional languages, 
but they have 100 times our manpower to throw at the problem.

Or we can play to our strengths by looking for markets where the 
negatives don't matter, or matter less than the positives.  Haskell 
offers a value proposition that is very different to conventional 
languages.  There is likely to be a market out there that is poorly 
served by conventional languages, but where Haskell will fit very 
nicely.  All we have to do is find it and target it.

Hmmm.  I wonder about simulation and testing.  Some time ago I asked 
here about doing discrete event simulation, and I have succeeded.  
(Unfortunately the resulting code is owned by my employer, so I can't 
share it).  QuickCheck has shown a new approach to testing.  Testing of 
stateful stuff using this approach would require a simulation of the 
thing to be tested.  This might be a winning proposition.

Paul.