Haskell’s motto is supposed to be “Avoid (Success At All Costs)”, but there seem to be varying interpretations of such.
For instance, the writer of GHC’s concurrency system, Simon Marlowe, ended up working for Facebook, which is a big data company that mines your information to sell to advertisers. Simon Peyton-Jones was employed by Microsoft Research for a long period of time, and we know that Microsoft used be “The Great Satan” of the 1990s. One of the biggest supporters of the Haskell ecosystem right now is IOHK, which specializes in blockchain technologies including Cardano and Ada, and a sizable portion of the Haskell is up in arms as they see cryptocurrency as a gigantic ponzi scheme.
There are also more severe interpretations of such. If you read “Being Lazy with Class”, “avoid success at all costs” seems to mean (but it’s not explicitly stated) that Haskell needs just the right level of success. “Being Lazy with Class” claims that Haskell was at the right level of production use; i.e, the production community was big enough to show how well Haskell performed in industrial use, but not so big that changes were impossible to Haskell or GHC.
An example of the opposite during early days is the existence of fmap; when the Functor type-class was first introduced, fmap was simply called map, but that broke a lot of code that was monomorphic to lists.
More recently, we had the simplified subsumption brouhaha, which I actually suspected was a trial balloon to see what would happen. This change broke a lot of existing code that depended on certain type-system behaviors that were considered unsound, and resulted in a sort of uproar among the production community. So -XDeepSubsumption became a thing to palliate the production community.
My personal interpretation of “Avoid Success At All Costs” comes down to two things. First, Haskell has an identity and changes that would break this identity are unwelcome. That means, for me, never first-class mutable variables, even though we have references to mutables (how are these not pointers?) living in IO, STM, and ST. We should not provide first-class support for object-oriented programming either; i.e, there should be no true object types with reflection supported by the type system. OOP libraries are welcome, of course, but never first-class support.
Second, Haskell should not evolve in an ad-hoc direction and major changes should be deliberate and careful. Consider the timetable of dependent types. Haskellers have been clamoring for dependent types for more than a decade now, yet I’d be surprised if support for dependent types came in before 2025 at the earliest. The GHC team is letting dependent types evolve via Idris, Coq, and Agda while waiting to see what a sensible and arguably best-in-class implementation of dependent types will look like.
On the other hand, I personally support Julie Moronuki and Chris Martin’s Haskell Phrasebook approach to Haskell, where right after case expressions, readers are introduced to the for-loop like function for_, and toward the end of a rather short text, readers are introduced to TVar as mutable variables.
I don’t think that this is breaking “Avoid $ Success At All Costs”, even though this is more of a practically-oriented approach wherein learners are allowed to mess around with more imperative constructs in Haskell (I consider all do-notation essentially procedural in cogition), while being encouraged to adopt a more functional style as they mature.
On the other hand, Haskell being taught as primarily a pragmatic language, as opposed to one fully wedded to powerfully-typed functional programming, represents to some “Success At All Costs”.
Likewise, what is your personal interpretation of “Avoid $ Success At All Costs”? Where are your red-lines to the language? Might it be, well, trying to pick up Javascripters? The Simple Haskell dialect? I believe some truly old-school Haskellers were outraged by the usage of monads, to begin with, and I personally dislike the necessity of code in do-notation, even if it’s often the most readable and maintainable way to express ideas.
===
Edit: I accidentally confused Chris Martin and Chris Allen. Chris Allen and Julie Moronuki did Haskell Programming From First Principles together for a while, but as many may know, there was a bit of drama. Julie Moronuki and Chris Martin are working together on Typeclasses.com, which produced the Haskell Phrasebook.
Thanks to duplode for catching this; I was tired and confused.