Hacker News Reader

Comment by throwaway110034 | Hacker News Reader

I will never, ever use Haskell in production because of its default evaluation strategy, the wrongness of which was tacitly conceded not long ago with the addition of the strictness pragma (which only works per-module) to GHC.

I think it's especially telling that its community skews so heavily towards this blogger/monad tutorial writer dilettante demographic rather than the D. Richard Hipp/Walter Bright 'actually gets real work done' demographic. I know which of the two I'd rather be in. Haskellers are even worse than Lispers in this regard. For the amount of noise about Haskell, you'd expect to see high-quality operating system kernels, IDEs, or RDMBSs written in it by now. Instead its killer apps are a tiling window manager, a document converter, and a DVCS so slow and corruption-prone even they avoid it in favor of Git.

View on HN

There is a fellow by the name of Jon Harrop who has in times pasted "showed up" when Haskell came up for discussion. To say that he does not like Haskell is putting it mildly. I have the impression that the mere existence of Haskell is a personal affront to him.

What struck me about your post was how much it sounded like something he would write, in particular the interpretation of facts (a strictness pragma was recently introduced to Haskell) in the most extremely negative way possible (said pragma is admission that Haskell's default evaluation strategy is simply "wrong").

If you are not he, you should look him up, as I expect you two (?) would get along fantastically.

> you'd expect to see high-quality operating system kernels

The Haskell community is smaller than others but there are numerous highquality projects, including kernel/OS level projects that you don't mention:

HaLVM, Haskell Unikernels - https://github.com/GaloisInc/HaLVM

The specification model of the sel4 microkernel - https://github.com/seL4/l4v/tree/master/spec/haskell

There are many smaller examples of OS projects in Haskell, but for better examples of production systems you only have to look to areas requiring high assurance such as finance, where a number of large companies use Haskell and other functional languages. (BoA, Barclays, Credit Suisse, Standard Chartered, etc.)

It's true that there a lot of Haskell blogs focused on research level Category theory, but the concepts there don't need to be used or understood for high quality, production ready code. I'm actually not a Haskell guy, and very much of the mindset that you should use the right tool for the job, but being dismissive of languages with unique features such as being lazy by default is shortsighted.

Would you also feel that a strict-by-default language which adds support for lazyness is a tacit admission that strict-by-default is wrong?

How would you feel if Common Lisps suddenly started sporting infix operator notation?

Haskel's alien, counter-intuitive evaluation strategy was actually marketed (circa 2010) as a powerful performance-enhancer that facilitated optimizations that were difficult if not impossible to do in a strict language like C. Instead, it ironically tends to cause more performance problems than it solves, with hard-to-debug spaceleaks capable of taking down production systems.

The entire Miranda branch of the PL tree is likely going to prove to be an evolutionary dead end, and Haskell will eventually lose out to Idris or some other strict language. And I don't think it's a coincidence that the strictness pragma (which does not even give you a strict program) was added soon after Idris and the rest started getting traction.

> How would you feel if Common Lisps suddenly started sporting infix operator notation?

You mean like this? (I linked it the other day.) https://github.com/rigetticomputing/cmu-infix But one might argue that the prefix notation + macros being able to support such a library is just further testament to their use as default...

In C# or Java, it's easy to get a lazy collection and force it into a list or an array. Is it possible to do the same with haskells (lazy) lists?

Array.fromList?

My impression on the consensus was that laziness was good for the tree (computation) but bad for the leaves (datatypes); hence the good practice of using strictness annotations on datatypes.

> hence the good practice of using strictness annotations on datatypes.

It's such a good practice that there's -XStrictData (different than the pragma mentioned by GP)

> I will never, ever use Haskell in production because of its default evaluation strategy, the wrongness of which was tacitly conceded not long ago with the addition of the strictness pragma (which only works per-module) to GHC.

Why must you publicly post something so wrong?

Because they have an axe to grind and a throwaway to burn?

Reply on news.ycombinator.com