How to grow the (commercial) Haskell user base?

[atravers]

[…] we need to find some way to ask those who don’t use Haskell […]

So what should we then do with all the comments that Haskell should have been strict by default? Here’s one option - have the authors of those comments read More points for lazy evaluation:

• Lazy bindings

  I like to tell Haskell beginners that any subexpression can be named and “pulled out”, modulo name capture, of course.

  […]

  This is (in general) just wrong in a strict language, of course. Just take the simple example

    if c then error "BOO!" else 0
  

  Which is not the same as

    let x = error "BOO!"
    in  if c then x else 0
  

• Lazy functions

  Even strict languages like ML and C have some lazy functions even if they don’t call them that, like SML’s if, andthen, and orelse.

• Lazy constructors

  […] Sometimes you need them, but in my experience it’s not very often.

  (But lazy lists were included in SWI Prolog as an option for streaming in 2019.)

• Reuse

  I’ve saved my biggest gripe of strict evaluation for last. Strict evaluation is fundamentally flawed for function reuse. […]
  Consider the any function is Haskell:

  any :: (a -> Bool) -> [a] -> Bool
  any p = or . map p
  

  It’s quite natural to express the any function by reusing the map and or functions. Unfortunately, it doesn’t behave like we would wish in a strict language. […]

  […] fusion [done manually] gets us to:

  any p []     = False
  any p (y:ys) = y || any p ys
  

  So where’s the function reuse? Nowhere in sight.

  With strict evaluation you can no longer with a straight face tell people: don’t use recursion, reuse the recursion patterns in map, filter, foldr, etc. It simply doesn’t work (in general).

There is no “free lunch” to be had from being strict by default - it has its own costs.

But if they’re still not convinced, here’s some more direct evidence to the contrary:

• Discus - http://discus-lang.org (formerly known as Disciple)

  • abandoned.

• Amy - GitHub - jdreaver/amy: Strict Haskell-like programming language that compiles to LLVM

  • no repository activity for about seven years now.

• Hamler - https://www.hamler-lang.org

  • no repository activity for about four years now.

A search for "strict Haskell" does find this concise presentation by Alexis King:

Laziness in Haskell – Part 2: Why not Strict Haskell?

…but surely that and similar content alone cannot be the reason why no strict dialect of Haskell has ever seriously challenged Haskell since 1990 - if even one in one hundred people dissatisfied with Haskell’s non-strict semantics over the last thirty years wrote a line of code for such a dialect, it would now exist (possibly instead of Rust).

Then there’s Mu:

• Functional programming reaches for stardom in finance - Risk.net

…whose front section is apparently now being replaced with GHC (no, I don’t know the specific details). For ease of interoperability, it seems SC has chosen to keep Mu’s syntax as close as possible to that of Haskell - also quoting from the reference in ReleaseCandidate’s post here:

What has been your experience using the [Mu] dialect and how does it compare
to writing regular Haskell?

After a while you don’t really notice! Apart from the difference in
operational semantics, as long as one is writing mostly vanilla Haskell
you can’t tell the difference.

So is this - finally - the sought-after evidence that Haskell being non-strict was…a mistake? And Haskell’s designers really should have made “the pragmatic decision” instead (strict/sequential semantics)?

Hmm - “pragmatism” ; I recall commenting on that in another “long and winding” topic…there it is:

My talk "Functional Programming: Failed Successfully" is now available!

So now that we’re back on-topic: why didn’t pragmatism work in 1978? Because if it did work, John Backus’s ACM Turing-Award lecture would surely have been about (some aspect of?) Fortran, rather than a “clarion call” for radical (at the time) change…

• (page 2 of 55)

  In 1978 John Backus delivered his Turing Award lecture, “Can
  programming be liberated from the von Neumann style?” (Backus,
  1978a), which positioned functional programming as a radical
  attack on the whole programming enterprise, from hardware
  architecture upwards.

  A History of Haskell: Being Lazy with Class (2007)

…and back in 1987, there already was a functional language with not just strict, but sequential semantics (due to the “pragmatic” choice of using effects directly). So what would have been the point of introducing another functional language with similar (strict but pure) semantics? It’s in large part due to Haskell having non-strict semantics that the benefits of purity can now be proclaimed with such certainty for all to hear (and read).

But as I’ve also commented elsewhere:

@atravers

[…] by themselves, purity and its benefits - referential transparency, ease of parallelism, etc - aren’t having much success elsewhere:

• The [[pure]] attribute, JTC1.22.32 Programming Language Evolution Working Group (2015)

  (page 11 of 17)

  As useful as pure functions seem to be, they also bring us some trouble. The most problematic drawbacks are in fact what makes pure functions useful in the first place.

• Monad I Love You Now Get Out Of My Type System (14:58)

  Multicore is here - why isn’t [functional programming] winning?

  Immutability

  Referential Transparency

  Purity

  Composability

  What’s not to like?

  …because it is not the code you want to write.

• [rust-dev] sub-grammar for range pattern constants?

  A long time ago we had an effect system and we made pure the default (since we didn’t want people accidentally leaving it out due to sloth) and we made the impure specifier a very small and reasonable keyword: “io”. […]

  Eventually people just took to making everything io, at which point it was a noise word and we decided to remove it (along with ‘pred’, which just meant pure, bool, and tracked by the typestate layer).

So purity and laziness work better together than apart.

Therefore all comments about Haskell’s non-strict semantics being the wrong choice in 1987 and since that time can be ignored.