[Haskell] Haskell as a disruptive technology?

[Krasimir Angelov]

As an author of HSQL and Visual Haskell I do agree that there is still
a lot to be done in order to make Haskell as popular as C++/Java in
the industry. We need strong support for GUI, Database, XML and many
other libraries that the other languages already have. The existing
development environments also need a lot of improvements. I know that
we already have many bits of that but it is still not enough.
Fortunately the situation is improving and now we have much better
libraries and tools than few years ago.

Cheers,
   Krasimir

2006/3/27, Paul Johnson <paul at cogito.org.uk>:
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>