Why does Haskell, in your opinion, suck? • Hacker News Board

Re: Why does Haskell, in your opinion, suck?

#151

Post by tome » Sun, Apr 17, 2016, 10:59 PM UTC

pron wrote: post #133

Peaker wrote: post #127

Earlier quoted context omitted.

It's not really Monads making the language more powerful. It's the taking away of non-pure primitives and libraries -- and replacing those with type-labeled effects. That these effects are composed monadically is a minor detail and unfortunately the thing that's emphasized. Haskell gains power in its framework for restricting code. In Haskell, you can know so much about what code doesn't do -- and that's what makes H…

> It's the taking away of non-pure primitives and libraries -- and replacing those with type-labeled effects. PFP and typing are quite orthogonal. You can have effect systems in non-PFP, continuation-based languages (i.e. languages that don't equate computations with functions). You can have non-pure, non-monad-based type-labeled effects. > Haskell gains power in its framework for restricting code. Sure, but Haskell…

> You can have non-pure ... type-labeled effects.

And what exactly would be the point of those?

Re: Why does Haskell, in your opinion, suck?

#152

Post by tome » Sun, Apr 17, 2016, 11:02 PM UTC

pron wrote: post #149

Peaker wrote: post #146

Earlier quoted context omitted.

> Clojure has STM and isn't pure at all. Not guaranteed STM. If you do IO in Clojure's STM, you just get a runtime error (assuming the IO does not forget to use the runtime-check that it isn't executing in STM context). > but there's absolutely no data to support this. Data of this sort is extremely expensive to collect reliably. I remember reading about a "GitHub study" that did not correctly classify what a "type e…

> Not guaranteed STM. If you do IO in Clojure's STM, you just get a runtime error Two things. 1/ "Guaranteeing" effects has little to do with PFP. 2/ There's no data to support that this level of guarantees has any effect on program quality. I'm all in favor of effect systems (though not PFP) because they're worth a try; but there's a long way to go from "interesting" and "it actually works!" especially if you have n…

Peaker started off by explaining that

> Haskell gains power in its framework for restricting code

and you have nudged the thread in the direction of your pet topic

> it's people who want to convince others to use Haskell that should collect some evidence in its favor

How exactly did we end up here?

Re: Why does Haskell, in your opinion, suck?

#153

Post by virmundi » Sun, Apr 17, 2016, 11:14 PM UTC

solidsnack9000 wrote: post #148

virmundi wrote: post #113

Earlier quoted context omitted.

It's that a monad looks pure, but actually isn't. Call addition with the same args and you should get the same answer. Calling next on a stream of io is destructive.

> ...a monad looks pure, but actually isn't. This is not true. The arguments for `next` include both: * The target stream. * A "state token" or universe. You get different results with different state tokens. At a high level, the thing to consider is that we can model all imperative programming with functional programming -- we can model Turing Machines with Lambda Calculus -- as well as go the other way around, beca…

Thank you for the explanation. Haskell's not as bad as I thought in this respect. My understanding was IO streams were a single input function (ie the stream). As a result the destructiveness would be less obvious.

Can you replay a get from stream by passing in an older token?

Re: Why does Haskell, in your opinion, suck?

#154

Post by tome » Sun, Apr 17, 2016, 11:16 PM UTC

pron wrote: post #105

devishard wrote: post #49

Earlier quoted context omitted.

This would be a reasonable critique except that monads are really why Haskell ends up being so powerful and composable. Sure, they can be tough to wrap your head around, but without them Haskell wouldn't be particularly special or useful.

It's more complicated than that. Monads don't make a language more powerful, but they are an absolute necessity given Haskell's design, which is built around extensional/value semantics, which basically approximates a program/subroutine as the function it computes; this is a useful approximation as it lets us treat computations as if they were referentially transparent. That approximation has a cost, though, as compu…

> Haskell's design, which is built around extensional/value semantics, which basically approximates a program/subroutine as the function it computes; this is a useful approximation as it lets us treat computations as if they were referentially transparent. That approximation has a cost, though, as computations are not quite functions (they are processes that compute functions)

This sounds "not even wrong" to me. Care to explain in more detail?

> If, OTOH, your language has continuations ... monads don't really help.

Haskell has continuations. Your move.

Re: Why does Haskell, in your opinion, suck?

#155

Post by tome » Sun, Apr 17, 2016, 11:19 PM UTC

nv-vn wrote: post #138

tome wrote: post #62

Earlier quoted context omitted.

> They rant against and mock everything deemed inferior. They treat people like they're idiots for not understanding basic but unfamiliar principles of the language. And nobody ever seems to shut them down, despite the fact that the majority are pretty welcoming. I'm happy to try to shut them down but I've pretty much never seen it (perhaps because I'm not in those other communities). If you do, please point me to it…

There were a few big controversies on Twitter and Reddit that I can recall. In one instance in particular, someone called out some Haskell users trying to make Haskell look better by publishing code examples of common algorithms that "cheated" (i.e. the Haskell quicksort that's so popularly paraded around isnt a true quicksort). After the person argued this, they were banned from the Haskell subreddit.

Can you link me to that?

I find it very hard to believe that someone would be banned from the Haskell subreddit for (correctly) pointing out that what has (curiously) entered Haskell lore as Quicksort is not really Quicksort. We all know this.

Re: Why does Haskell, in your opinion, suck?

#156

Post by sid-kap » Sun, Apr 17, 2016, 11:54 PM UTC

oldmanmike wrote: post #102

PeCaN wrote: post #96

Earlier quoted context omitted.

How about OCaml? It's not as theoretically advanced as Haskell, but it gets work done, is easy to read, fast, easy to reason about the complexity of, has decent libraries, and is generally quite pleasant.

I would be interesting in learning more about the "easy to reason about the complexity" part of OCaml. The problem I'm having with Haskell isn't that it's too slow, but that it's so high-level and gets so aggressively optimized at compile-time, that the performance of the resulting binary has performance characteristics that are unpredictable and non-deterministic. Performance can regress between GHC releases, for in…

Not trying to detract from your point, but it's interesting to note that even C and x86 are "pretending modern computers work in a way they don't" (see http://blog.erratasec.com/2015/03/x86-is-high-level-language...).

Re: Why does Haskell, in your opinion, suck?

#157

Post by noblethrasher » Mon, Apr 18, 2016, 12:06 AM UTC

sillysaurus3 wrote: post #52

iak8god wrote: post #41

Earlier quoted context omitted.

Incidentally, this is why prefix notation seems so foreign. (+ 1 2) reads as "plus one two." It might just be the Lisp version of Stockholm Syndrome, but it seems perfectly natural to me to gloss that as "Add one and two."

Good point. (eq (+ 1 2) 3) would read "is add one to two equal to three?" though.

One thing that long ago helped me to apprehend and appreciate the power of functional programming was to start thinking descriptively (in terms of facts and propositions) rather than prescriptively (in terms of imperatives and commands).

Thus, I read “(+ 1 2)“ as “the sum of 1 and 2” rather than ”add 1 and 2“. Similarly, I read ”(eq (+ 1 2) 3)“ as ”the difference between 3 and the sum of 1 and 2 is zero“.

Re: Why does Haskell, in your opinion, suck?

#158

Post by akavel » Mon, Apr 18, 2016, 12:08 AM UTC

skybrian wrote: post #75

tome wrote: post #69

Earlier quoted context omitted.

> I don't like having to learn all that by heart before I even start with the language I'm very curious about this. Why do you think you have to learn it all by heart before you start with the language?

I'd guess this happens when you don't know an easy way to look up the definitions on the fly.

Also I meant it about having to memorize the spelling.

Re: Why does Haskell, in your opinion, suck?

#159

Post by Tinned_Tuna » Mon, Apr 18, 2016, 12:44 AM UTC

I actually really like the language, but there are several key points which stop me from using it in any production systems:

First and foremost, the build system. Oh god, the build system. Cabal is wonderful in some respects, but I have often found myself in a situation where the answer is "delete the ~/.cabal and ~/.ghc-pkg". This should not happen.

Laziness. You get concise programs, but then the memory performance is unknown until you read it and/or learn to read GHC's IR. You know, I'd really enjoy being able to know roughly how much memory I need to buy up for the systems I'm deploying.

Experimental or non-standard extensions. Just no. I'm not going to rely on non-standard or experimental "stuff" that tie me to a single compiler. This is made all the worse in that they're all hard-bound to various GHC versions and you're expected to use them in production (I'm looking at you, web frameworks). We have standards, stick to them.

It is for these reasons that I can't recommend Haskell to people as anything more than an interesting language to learn. Until the above is fixed (many of which are cultural) I will not use Haskell in production.

Re: Why does Haskell, in your opinion, suck?

#160

Post by kccqzy » Mon, Apr 18, 2016, 4:31 AM UTC

yongjik wrote: post #104

I only dabbled in it a little for fun, but in my beginner's opinion: Pros: The compiler eliminates a lot of potential bugs, so once my code compiles, I've saved hours that would have been spent debugging if I were using, say, C++. However, Cons: It takes more hours to figure out why my code is not compiling! Basically, instead of debugging my code, now I have to "debug" GHC, trying to figure out what it is thinking a…

If you prefer the "quick and dirty" way, you can use the flag -fdefer-type-errors to turn type checker errors into runtime errors that throw exceptions.