1. Talk about it in isolation: we enjoy Haskell, here's where we think it should go.
2. Place it in the context of the wider software ecosystem, as in these are the pros and cons, barriers to adoption etc.
What isn't effective is doing #2 while not trying to really engage with reality. If you just assume, contrary to evidence, that Haskell is the right way and the reason it's not adopted more is that everyone insists on doing things the wrong way, you will not convince anyone who doesn't believe this fairy tale already, and worse, you'll ensure you won't help yourself, because you focus on the issues you wish you had rather than the issues you actually have. Self-reflection is supposed to help you, and it only helps if it's a long hard look in the mirror. The approach of, "things aren't going the way we hoped but our assumptions could not possibly be wrong so we'll just examine everyone else's" is not generally useful, as it's nothing but a waste of time: you know you'll end up exactly where you started.
How far do you want to take the eager execution thing?
Should we get rid of boolean short-circuiting?
Should if-statements evaluate both the true and false paths before choosing one?
Should compilers no longer remove dead code?
This to me, is the only reply thus far that addresses what I also perceive to be the fundamental problem with Haskell - it doesn't provide any new convenient tools to solve real world problems, while requiring one learns a bunch of useless abstractions that aren't used anywhere else in industry as a default (monads, laziness, immutability)
But more importantly, immutability is used everywhere in the industry.
However the problem with the parent post of that it presumes Haskell isn't useful because of X, when clearly it's useful for many and changing X would make it not Haskell. That sort of comment isn't useful.
I think for as long as I have known Haskell (1992-) there has been interest in and a desire for a strict variant of Haskell. In 2020 it seems there are a lot more options for that, which is great, but they aren't Haskell.
this seems like some version of a No True Scotsman argument.
Should not be controversial at this point.
For Haskell to succeed, it has to move away from rigid commitment to various pure functional paradigms and move to eager execution by default. But Stephen does not help this, just preferring to instead dig in more on expecting the reality of the rest of the world to change itself to accommodate the strictures under false pretense that the strictures are parochially better.
Haskell’s real failure to launch is not because of complex tooling issues between cabal & stack, not because of a big mess of compiler pragmas to get basic String functionality, not due to complexity of understanding monads or type classes.
The problem is that the stated benefits of pure functional programming are not actually benefits at least not when writing business software.
The slides (rather arrogantly) say we’re at the blood-letting and leeches stage of software. Well claiming Haskell is a solution is like inventing epicycles to explain orbits or elevate alchemy to a science. It wastes everyone’s time with artificial complexity substituted for advanced capability.