New Blog post: Haskell - Doomed to Succeed?

Awaiting your feedback!


I can’t resist!

As you say in your post, “Avoid success at all costs” was always intended as a play on words. Of course I never really meant “Avoid success, at all costs”; that was the joke. What I mean was: Avoid success-at-all-costs

That is, let’s cleave strongly to Haskell’s key principles, even is they seem to stand in the way of short-term “success”.

An example is I/O. For literally years Haskell had no I/O to speak of; more precisely, I/O was unreasonably difficult. For practical utility that was pretty inconvenient. But we stuck to purity… and eventually worked out how to combine purely functional programming with I/O, via monads. And that in turn has been a pretty influential idea.

So the point is not to avoid success; but rather to stick closely to Haskell distinctive, principled ideas, and believe that doing so will, over time, lead to success, albeit perhaps success of an unexpected kind.

So I don’t quite agree with your formulation “So while SPJ claims to have been saying “don’t divert too much effort from the main goals to make the platform appealing to production users,”…”. Actually I think that making the platform appealing to production users really is a major goal! It just that I don’t want to make fundamental compromises of core principles in pursuit of short-term production goals.

I think we all agree about this, and it’s what the HF site says on the front page:

  • Faithfulness to Haskell’s founding design principles. Haskell’s design puts principle ahead of expediency by cleaving closely to the principles of purely functional programming.

Thank you. I will update to reflect your comments.

@simonpj I have made some changes to the post.

1 Like

For whatever it’s worth, here is a comment from a Haskell learner, so still an outsider (I still don’t grok monads and am not yet convinced they are good), but a long-time fan of FP.

I think that avoiding success-at-all-costs is what makes some languages so convenient and practical. Yes, it can lead to success! I’m sure that this is why Haskell and Clojure are as popular as they are. It’s why the benevolent-dictator-for-life model of language control is good when the dictator is wise. With Clojure, for example, I think it’s Rich Hickey’s informed choices and resistance to adding everything that everyone wanted that makes Clojure such a joy to use (even though I have chafed at some some limitations that Hickey imposed).

With Haskell, even though it doesn’t have a BDFL, I’d bet that the resistance to success-at-all-costs is part of what makes Haskell such a joy to use, and therefore practical (at least the non-modadic part! :slight_smile: ).

The joy comes from great power and flexibility with great ease and conceptual simplicity.

As an outsider, I don’t know anything, but I have some worry that basing future developments on committees and quick interaction with the community risks leading to inelegant growth of the language. In the Clojure model, there’s certainly input from the community, but you don’t always know what’s done with it. This sometimes frustrates users. But the end result is mostly excellent, and that’s good enough for me. (I like democracy in societies, but in language design I just want good design however it comes about. Voting then takes place on the resulting package, to some extent.)

Whatever institutional structures and communication patterns are put in place by the new foundation, I hope that it preserves the beauty, simplicity, and utility of the language.

My two cents.


Thank you Ari!

(Apparently Discourse posts must be more than 20 chars, so I’m adding some.)

1 Like