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