Why does Haskell, in your opinion, suck?

> Care to explain in more detail?

What exactly is unclear? In Haskell, a subroutine or a subprogram is modeled as a mathematical function. Programs are not exactly functions[1] but continuations (i.e., they are a process which can be paused and resumed). There's absolutely nothing wrong with abstracting computations as functions (and there's much to be gained, which is why programmers are encouraged to write pure functions where possible, regardless of the language they're using), but sometimes you need to use their continuation-quality, and that's when you need monads.

> Haskell has continuations. Your move.

No, it doesn't. It models continuations as monads which is precisely my point. If Haskell subroutines were continuations, it wouldn't need monads, just as OCaml doesn't.

[1]: If they were, then computations would be extensionally equivalent like functions, but they're not: an observer can tell if you're running bubble sort or merge sort, even though they're computing the same function (which is why type theory introduces has the concept of definitional equality). A lambda term or a Turing machine are not functions but continuations; you can start reducing a lambda term (or running a TM), block it (i.e. capture the reduced term/TM state), and then resume it.

I started off by explaining why Haskell needs monads and why they don't add power, and later why PFP and restricting what code can do are orthogonal. Peaker then spoke of tangible gains, and I said that something is not tangible if you can't show it, and then you nudged the thread in the direction of your pet project which, apparently, is patronizing people.

More to the point, if you claim Haskell (or, in particular, monads) has theoretical benefits, you need to be able to explain them (and restricting effect is not a theoretical explanation as it doesn't require monads); if your explanation is "this has benefits in practice" then you're really claiming empirical, rather than theoretical, benefits, but then you need to be able to support those. If you go around saying monads have theoretical benefits but when debated claim empirical benefits and then don't support those, expect to be called out for selling snake-oil (and just to be clear, my point can be summarized as follows: Haskell takes a very clear, very opinionated theoretical approach[1], which is beautifully elegant but is not theoretically better or worse, just very different, with its particular pros and cons. Empirically, I claim, Haskell has not yet shown significant benefits).

[1]: Subroutines as functions; mutation as effect; HM types (+ typeclasses). Type system aside, there are obviously many alternatives (other than "classical" empirical languages). For example, languages that require full verification for safety-critical realtime code often employ the synchronous model. In that model, each subroutine isn't a function (but a continuation), but the program itself can be viewed as a function from one program state to the next, and mutation isn't a side-effect, but is very much controlled (see https://who.rocq.inria.fr/Dumitru.Potop_Butucaru/potopEmbedd...). This is a model that lends itself very nicely to formal reasoning, and there are others.

How big were such projects?

I never saw a C project with teams bigger than 5 developers without memory corruption issues.

I'm sorry, I really don't understand.

My definition of pure language is "The language can encode a large class of non-side-effecting computations, and you can tell that they are non-side-effecting from their type". If you are in a non-pure language you cannot distinguish side-effecting from non-side-effecning computations just by looking at their type and thus, working with my definition, it seems impossible to have type-labelled effects in a non-pure language.

What exactly is your definition?

> if your explanation is "this has benefits in practice" then you're really claiming empirical, rather than theoretical, benefits, but then you need to be able to support those

I disagree strongly with your position on this.

Peaker has clearly found, as I have, that Haskell is more effective for him. We have pointed out repeatedly what the benefits are (as well as pointed out the drawbacks). It would be simply impossible for the stated benefits not to be beneficial in practice. The only question is whether the benefits are outweighed by the drawbacks. If you have already paid the one-off cost of learning the gnarly corners of Haskell then those drawbacks are significantly diminished.

You must realise that your insistence on empirical research is an idosyncracy and that people make decisions on programming languages all the time without such research. They are not, in its absence, merely "guessing" which language to use. They are making a decision based on their understanding of their own needs and on the strengths of the languages under consideration.

Furthermore, I wouldn't trust any empirical research on languages any more than I would trust empirical research on cholesterol[1].

In the absense of convincing empirical research pointing in either direction I think people should be free to make informal claims that "Haskell is more reliable than Python and more productive than Ada" based on their own experience and the experience of their colleagues. It's all we've got to go on. It's not ideal, but it's also not wrong.

[1] http://www.cbc.ca/news/health/old-cholesterol-warnings-steep...