[Haskell-cafe] Research language vs. professional language

Ryan Ingram ryani.spam at gmail.com
Mon Sep 1 04:07:28 EDT 2008


Jonathan, I think we are going to end up just disagreeing on this
subject, but I'd like to point out the reasons why we disagree.

On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast
<jonathanccast at fastmail.fm> wrote:
> This concept of `day-to-day work' is a curious one.  Haskell is not a
> mature language, and probably shouldn't ever be one.

I see where you are coming from here, but I think that train has
already started and can't be stopped.  I find Haskell interesting as a
professional programmer for these four reasons: it's pure, it's
functional, it's lazy, and it's got a great compiler.

I don't know of any other "mature" language that can fill these shoes;
Haskell is the most mature of them.  If I'm missing another language
that fits my requirements and would be better for day-to-day
programming, let me know!  The serious competitors I can see are Clean
(Hackage blows away anything I've seen from that community) and
O'CaML, which is neither pure nor lazy.

Meanwhile, Haskell is getting more suitable for regular "professional"
use every day.  Look at the success of Hackage and the
soon-to-be-published "Real World Haskell" book for evidence.  Haskell
solves many of the problems I have with existing languages today, and
makes me a better programmer at the same time.

> There will always be new discoveries in purely functional programming,
> and as the art advances, features like this ad-hoc overloading hack
> (and ACIO) will become obsolete and have to be thrown over-board.

This is a good point.  However, it seems to me that the pure
programming language research is moving towards dependently typed
languages, and that progress in Haskell has been more
application-side; transactional memory and data-parallel, along with
research on various fusion techniques, for example.

I also think ACIO is a good theoretical starting point for research on
what initialization means, and has potential for work to influence the
commutative monads problem in general which could improve the syntax
and number of lines of code devoted to working around the verbosity of
effectful computations in Haskell.

> I'd rather (much rather!) people concerned with day-to-day programming
> for writing programs people actually use incorporate Haskell's features
> into other, more practical, languages (as those who *actually* care about
> such things are) rather than incorporating features from day-to-day
> production languages into Haskell.

This is already happening, of course; I think ML is going to become
pure soon, although I don't think it will ever be non-strict.  And I
predict that within the next few years, lots of languages will be
leaning heavily on the concurrency research that is going on in
Haskell right now.

But Haskell's community is also growing and becoming more
results-oriented.  If you want to blame someone for this, Don Stewart
is probably your guy :)  I'm just one of the johnny-come-latelies who
is realizing what a great tool Simon and the rest of the ghc team has
built.

So, my question for you is: if Haskell is a research language, what
direction should it be taking?  What changes should be happening at
the language (not the library) level that are in the interests of
improving the state-of-the-art in functional programming?  My goal is
to make it not be a joke when I go to work and suggest that we use
Haskell for part of our next project.  What is yours?

   -- ryan


More information about the Haskell-Cafe mailing list