Comment by mlthoughts2018 | Hacker News Reader

Comment by mlthoughts2018 | Hacker News Reader

Parent Full thread

When will Haskell get a different spokesperson? Stephen isn’t effective in this role. These posts have jumped the shark to the point when I see a big Haskell post on HN and see stephendiehl.com it’s just time to tune out.

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.

Right. If you want to talk about your language, there are two effective ways:

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.

> For Haskell to succeed, it has to move away from rigid commitment to various pure functional paradigms and move to eager execution by default.

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?

Many languages have already figured out good trade offs, why shouldn’t we expect a high standard of Haskell?

The types of posts that get downvoted on here is at times maddening.

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)

If you remove monadic IO, laziness and immutability from Haskell, then you're a lot closer to OCaml than you are to Haskell.

But more importantly, immutability is used everywhere in the industry.

(It's a HN rule not to discuss down votes)

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.

> “ changing X would make it not Haskell”

this seems like some version of a No True Scotsman argument.

"Favor Immutability" - Effective Java, circa 2001

Should not be controversial at this point.

Immutability is great. What does that have to do with Haskell?

Reply on news.ycombinator.com