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