Live data from Hacker News

Why does Haskell, in your opinion, suck?

reddit.com

141–150 of 208 posts

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

#141
post #92

Haskell has 3 major problems that are completely distinct in my opinion. Biggest technical problem: lazy evaluation. Other people have said more than enough here. Biggest cultural problem: technical oneupmanship and code golf. Haskellers can get so caught up in no-compromises stylistic competition that it makes it hard to get anything done. If you finally finish up something that accomplishes your goals, your teammat…

Lazy IO's an issue, but Lazy Evaluation? It's not that different from writing SQL, and the places where it is, it's a lot more consistent, predictable, and tuneable. It's usually just bad defaults like Lazy IO, or String instead of Text that get you, but there's some consensus to move away from that. There are definitely some toxic assholes, as in any community, and it's really shitty if they're going to, e.g., /r/ja…

I don't think people mean to attack you, and it's really difficult for me to understand why the comment you linked could be considered offensive.

I understand you have a certain love for Haskell, and that's a wonderful thing. But not everyone appreciates it as much as you do. One person's artful philosophy is another person's mental masturbation. And both people are entitled to their opinions.

Perhaps you decided to stop reading immediately after you searched for that comment, because you'll see the top reply agrees with your opinion.

There is no "anti-intellectualism" here. There are people who want to get something done at any cost, and there are people who think the journey is more valuable than the destination. Both people have a reason to think they're correct, and neither perspective is any more valuable.

You're on a forum run by a Silicon Valley VC, for goodness' sake. What opinion do you think you'll hear most here? Probably not the same one you'd hear from the wonderful folks on #haskell. It's not "anti-intellectual", it's different.

(also, there are more FP lovers here than you think.)

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

#142
post #137
post #133

Earlier quoted context omitted.

> 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…

> PFP and typing are quite orthogonal They are orthogonal in 1 technical sense. But the benefits are reaped from the combination. > the PFP abstraction has so far failed to yield results commensurate with its cost. You say this based on what? Me and other Haskell users believe that the costs are very minimal and the benefits are quite huge.

> But the benefits are reaped from the combination.

Well, I happen to think that some forms of rich typing are quite beneficial, but that value-semantics is a negative. I don't see Haskell having any tangible benefits whatsoever over, say, OCaml (other than ecosystem-related stuff), which has one (relatively rich typing) but not the other (PFP).

> You say this based on what?

Based on the fact that the few Haskell shops out there -- despite them being composed of avid enthusiasts and people who devote a lot of thought into the Haskell way of thinking, are not reporting even 2x productivity gains (although I don't know what huge means to you). I mean, some say they feel those gains, but when you look at iteration speed, time to market etc., you see negligible advantage if at all. As to the cost, I won't argue with you, but I encourage people who are interested in languages as well as in software engineering to try Haskell and judge for themselves.

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

#143
post #142
post #137

Earlier quoted context omitted.

> PFP and typing are quite orthogonal They are orthogonal in 1 technical sense. But the benefits are reaped from the combination. > the PFP abstraction has so far failed to yield results commensurate with its cost. You say this based on what? Me and other Haskell users believe that the costs are very minimal and the benefits are quite huge.

> But the benefits are reaped from the combination. Well, I happen to think that some forms of rich typing are quite beneficial, but that value-semantics is a negative. I don't see Haskell having any tangible benefits whatsoever over, say, OCaml (other than ecosystem-related stuff), which has one (relatively rich typing) but not the other (PFP). > You say this based on what? Based on the fact that the few Haskell sho…

There are a lot of tangible benefits over, say, OCaml. Let me use one particular representative one: STM.

Haskell can successfully implement a performant STM with static guarantees regarding transactions. How would you add practical, guaranteed STM to OCaml?

> are not reporting even 2x productivity gains

An overall 2x productivity gain is huge. A 10% productivity gain is worth millions over the course of a year, for even a medium-sized software shop.

There are other, very productive languages (at least for initially writing programs) but they tend to be far less reliable. There are other relatively reliable languages (e.g: Ada) but they are far less productive.

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

#144
post #143
post #142

Earlier quoted context omitted.

> But the benefits are reaped from the combination. Well, I happen to think that some forms of rich typing are quite beneficial, but that value-semantics is a negative. I don't see Haskell having any tangible benefits whatsoever over, say, OCaml (other than ecosystem-related stuff), which has one (relatively rich typing) but not the other (PFP). > You say this based on what? Based on the fact that the few Haskell sho…

There are a lot of tangible benefits over, say, OCaml. Let me use one particular representative one: STM. Haskell can successfully implement a performant STM with static guarantees regarding transactions. How would you add practical, guaranteed STM to OCaml? > are not reporting even 2x productivity gains An overall 2x productivity gain is huge . A 10% productivity gain is worth millions over the course of a year, for…

> How would you add practical, guaranteed STM to OCaml?

I don't see the relevance. Clojure has STM and isn't pure at all. I can't see why OCaml cannot do the same.

> There are other, very productive languages (at least for initially writing programs) but they tend to be far less reliable. There are other relatively reliable languages (e.g: Ada) but they are far less productive.

I understand that the Haskell community wishes this to be true -- and maybe it is -- but to date there's no data to support this. Whatever little data we have on bugs (the "GitHub study", which might not be dependable, but that's all we have) shows negligible-to-nonexistent advantage to Haskell over other languages.

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

#145
post #122
post #77

Earlier quoted context omitted.

> Biggest technical problem: lazy evaluation. Other people have said more than enough here. I am actually wondering about that. It is considered essential by the classic paper "Why functional programming matters", for better program composition. In particular, I wonder how are you supposed to pass around IO monad (or any other thing whose evaluation will give you side effects) as a value, if you have strict evaluatio…

Laziness and IO are unrelated. Idris, as you mention, is eager and strict -- and is still pure and uses IO in the same way as Haskell. Evaluation in Haskell does not cause side-effects, including evaluation of IO action values. It is the execution of these IO actions (by the RTS, due to their inclusion in `main`). For example: let x = map print [1..10] :: [IO ()] x is just a list of values, each representing the acti…

Ah, OK, thanks for explanation!

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

#146
post #144
post #143

Earlier quoted context omitted.

There are a lot of tangible benefits over, say, OCaml. Let me use one particular representative one: STM. Haskell can successfully implement a performant STM with static guarantees regarding transactions. How would you add practical, guaranteed STM to OCaml? > are not reporting even 2x productivity gains An overall 2x productivity gain is huge . A 10% productivity gain is worth millions over the course of a year, for…

> How would you add practical, guaranteed STM to OCaml? I don't see the relevance. Clojure has STM and isn't pure at all. I can't see why OCaml cannot do the same. > There are other, very productive languages (at least for initially writing programs) but they tend to be far less reliable. There are other relatively reliable languages (e.g: Ada) but they are far less productive. I understand that the Haskell community…

> 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 error" is. Is that the one?

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

#147
post #25
post #15

Haven't seen it listed neither here nor there, so not sure if I'm the only one, but: for me, the first and currently blocking obstacle is of "graphical" syntax. I'm of the kind of people who hear the words they read as a voice in their head, so when every line is interspersed with multiple "random" >>= -,-'-- and whatnot other ascii-art I can't verbalise, I distictly feel my brain stumble, mumble, and grind to a halt…

I felt the same way (and still do in general, with notable exceptions). I.e. to put this first: I think a lot of the Haskell community is obsessed with mathematical "cuteness", which basically they take to mean "infix-operator-heavy" notation. Nevertheless, I have learned to like some operators, , *>, are ones that come to my mind. The operator is basically fmap as infix notation, so `fmap f [1,2,3]` would be `f [1,2…

It helps to read $ as "value". Then "function $ x" is "function value (of/at) x". Works in some other languages too, e.g. $VARNAME = value (of) VARNAME.

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

#148

Earlier quoted context omitted.

The IO monad doesn't involve actually recording anything...it's not like MVCC. What are you actually trying to say here?

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, because Turing Machines and the Lambda Calculus are, for all intents and purposes, equivalently expressive.

Modeling IO with state monads isn't a hack; it's the point.

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

#149
post #146
post #144

Earlier quoted context omitted.

> How would you add practical, guaranteed STM to OCaml? I don't see the relevance. Clojure has STM and isn't pure at all. I can't see why OCaml cannot do the same. > There are other, very productive languages (at least for initially writing programs) but they tend to be far less reliable. There are other relatively reliable languages (e.g: Ada) but they are far less productive. I understand that the Haskell community…

> 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 no data to support this.

> Data of this sort is extremely expensive to collect reliably.

Fine, but the alternative is to use an unproven, negligibly adopted (Haskell industry adoption rates are between 0.01-0.1%), badly tooled language, that requires a complete paradigm shift on faith and enthusiasm alone. I don't need, or want, to prove that Haskell isn't effective (TBH, I really wish Haskell, or any other novel approach did have some big gains); it is Haskell's proponents that need to support their claims with at least some convincing evidence.

> Is that the one?

I don't remember, but what does it matter? Again, I don't want to prove Haskell's ineffectiveness; it's people who want to convince others to use Haskell that should collect some evidence in its favor.

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

#150

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…

One thing that helps A LOT when it comes to those compiler error messages is writing lots of type signatures. They help keep the error messages more "localized" than they would if you rely on global type inference. I would recommend at least writing a type signature for every top-level function in your programs.

That said, Haskell still has many features that make errors more complicated than other languages. One example is that the use of whitespace for function calls means that some things (like forgetting a comma in a list) become type errors instead of syntax errors. Another example is the overloaded numeric literals, which add "invisible" typeclasses to any code you write that uses numbers.

Coming back to your comment, I think that the "quick and dirty" bit has more to do with you being more used to C++ than you are with Haskell. You can also write dirty code in Haskell if that is what you really want :)

Post reply on HN