ryani.spam:

On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast 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.

Yeah, it's too late. Too many people have their pay checks riding on GHC, the Hackage library set (now up to 740 libraries and tools!), and the continued development of the language in general. If Haskell's not "mature" yet, then perhaps it has reached its early twenties, with an reliable heavy duty optimizing compiler, fast runtime, large library set, standard documentation, testing, debugging and packaging tools, and large community. And a community with a lot of energy. We're serious about this thing. -- Don

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

Ryan Ingram:

On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast 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. [..]

...

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.

Let me quote from the Preface of the Haskell report:

It was decided that a committee should be formed to design such a language, providing faster communication of new ideas, a stable foundation for real applications development, and a vehicle through which others would be encouraged to use functional languages.

and

It should be suitable for teaching, research, and applications, including building large systems.

From the outset, the Haskell vision included being a "stable foundation for real applications development" (I read this as aiming at industrial use) and "research". This leads to tension, but, for better or worse, I believe that the Haskell community -in its current form- is pretty much committed to meet both goals. You can see it in GHC. It implements the static Haskell 98 and at the same time many experimental, researchy features (which you use at your own risk). More generally, I think that this is one of the killer features of functional languages, they provide a fast path from innovative, even highly theoretical research to practical applications. This may not work forever -maybe all interesting research that can be done in Haskell without radical changes will have been done at some point- but for the moment, I think we are in pretty good shape. Manuel