[Haskell-cafe] Re: Research language vs. professional language

[Jonathan Cast]

On Mon, 2008-09-01 at 01:07 -0700, Ryan Ingram wrote:
> 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.

I hope not.  When I used the word 'mature', I used it in the most
negative possible sense: subject to industrial backwards-compatibility
requirements that ensure that no feature is ever removed.
Backward-compatibility is necessary for real-world languages, but it
also seems to be the source of most of the really ugly interfaces in the
computer industry.  I think Haskell has to have the freedom to discard
features --- even at the expense of backward compatibility --- if it is
to continue producing neat ideas for making programming better.  That's
a deeply-held conviction, it's not a pragmatic `we need to discard foo
now to get bar in'.  By the time you reach that conversation, the
decision for or against backward-compatibility has already been made.  I
want it made correctly (and both choices are correct, which is why I
think we need two languages *both* of which take Haskell' as their
starting point).

>   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,

But it's not there yet.  In particular, I haven't seen a self-hosting
dependently typed language; the tools seem to all be written in Haskell.
So I think Research Haskell will still be needed, for a while.

>  and that progress in Haskell has been more
> application-side; transactional memory and data-parallel, along with
> research on various fusion techniques, for example.

Of course, it could also be argued that language-design issues are being
neglected, and hacks are being adopted without due consideration for
good design.

> 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

This is good!

>  and becoming more
> results-oriented.

This is not; see my other post.  I think it's great that Haskellers are
starting to accomplish useful things, but if in the process I think
elders like Lennart Augustsson and Paul Hudak are starting to be
ignored.  Hair-shirt wearers need to have someplace to live.  Up until
recently, that's been Haskell.  I can't help seeing putting things like
ad-hoc overloading or ACIO into Haskell as theft of that territory from
them, and I think it's incumbent upon those who would do such a thing to
propose where the hair-shirt wearers are going to receive asylum now
that they're being expelled from Haskell.

(Sorry if that paragraph comes across overly strong, but I really do
care strongly about this.  I think keeping Augustsson, say, happy with
the design of the language and libraries he uses is one of the most
practical things we can do for the programmers who come after us, and
I'm passionate about it.)

>   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?  

As for language changes, I can think of only two semantic changes made
to Haskell at the language level (in its existence) that are, even in
Haskell', mature enough to standardize: (single-parameter) classes and
constructor type variables.  There have been a few bits of syntax sugar
that represented significant break-throughs, as well (especially
do-notation), but those were concomitant with library changes
(everything about monads, except the do-notation syntax sugar, is a
library feature, not a language feature).  So I'm not going to accept
that distinction.  What I think are the most important research areas in
Haskell:

* First-class existentials.  We think we know how to do this, but I'm
sure somebody could get published putting it into a mature Haskell
compiler.
* Extensible records.  See above.  This exists at the library level in
HList, but it could use more compiler support.
* Mutable variables.  (These aren't in either Haskell 98 or, IIUC,
Haskell', btw.).  I haven't really seen a good denotational semantics
for these yet, and SPJ's operational semantics leads to bizarre language
restrictions like not generalizing the type of a variable introduced by
<- (as was proposed in Wadler's very first monad paper).  I really don't
think we understand from first principles how these work in a
purely-functional language that's committed to Hindley-Milner typing and
parametric polymorphism yet.
* Non-parametric polymorpism.  This is needed not just for Typeable
(which really, really, really doesn't belong as a pure library), but
some language modification is needed for IORefs, as well.  I don't think
we've heard the last word on any of these, as well.
* Dynamic typing/dynamic loading.  hsplugins seems to work in practice,
although I'm a little suspicious of it (I'd investigate it further, if I
hadn't discovered that running ghc -e from a perl script was as easy to
use and guaranteed correct, to boot), but I'd like to see more follow-up
on some of the original dynamic typing ideas.  Again, we're treating
dynamic typing as a library feature, when it's really a language
feature.
* The first-class type classes from SYB III.
* Bytestrings make me uncomfortable: why isn't GHC's list implementation
good enough?  In general, I don't think in 20 years programmers will
still be picking data structures at that level.

> 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?

My goal is to ensure there's an even better language to propose using 10
years from now.

jcc