Live data from Hacker News

Why does Haskell, in your opinion, suck?

reddit.com

41–50 of 208 posts

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

#41
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'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 and sad emptiness. Incidentally, this is why prefix notation seems so foreign. (+ 1 2) reads as "plus one two." It's possible to overcome this, with dedication.…

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."

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

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

Interesting that Haskell goes in so hard for operator overloading. In other languages I've used, while you can overload a bunch of operators, it's not a common thing to encounter, outside of math code, where it makes the most sense. Technically you could do all sorts of crazy operators in C++, but that tends to be frowned upon in that community.

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

#43

Earlier quoted context omitted.

Binary search sounds kind of 2D. Wolf fence also lets you work with unsorted data. I.e. if I asked you to find a squeaky noise coming from somewhere in your house. Does it make sense to "binary search" your 3D 3-story house? Wolf fencing makes more sense.. stand on floor 2, see if it is on your floor. Or is it coming from the stairwell to floor 3, or the starwell to floor 1? You just used 1 step to narrow your search…

How can wolf fencing work on unsorted if you have to find out where it happens? Wouldnt that involve iterating on each item to find out where the wolf is?

You can search N objects in less than O(N) time if you have a way of testing multiple objects at once. Pre-sorting is one way to obtain this capability, but it's only one of many. Often the capability comes from the problem domain itself (or, more accurately, how you model time in your problem domain). In debugging, "one run of the program" often decently approximates a constant unit of time, and you can (theoretically) bisect once per run, giving you the ability to search without an explicit presort. In the wolf analogy, your ability to roughly determine which direction the wolf call is coming from does the same thing.

In both cases you could argue that you are "cheating" because there is a computational process of some kind doing at least O(N) work each time (the computer in the debugging example, the universe in the wolf example), giving O(NlnN)+ overall, strictly worse than an O(N) linear search. However, you have to ask yourself in this case if it makes sense to equate the time taken by the computer/universe to run one unit of its computation with the time taken to run one unit of your* search, and in many cases it doesn't. In the end it's just a model and it's up to you to choose what to measure, approximate, and exclude.

If someone tries to argue that there is fundamental philosophical truth that makes one model better than the other, start digging down into the physics of the CPU -- how much O(N^N) quantum computation did the universe have to do in order to bring you a single CPU cycle? God only knows, but the time it takes is nearly constant, so it makes sense to ignore. Even the most hard-core theoretical algorithms expert is just as "guilty" of this kind of approximation as you are :-)

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

#44
post #42
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…

Interesting that Haskell goes in so hard for operator overloading. In other languages I've used, while you can overload a bunch of operators, it's not a common thing to encounter, outside of math code, where it makes the most sense. Technically you could do all sorts of crazy operators in C++, but that tends to be frowned upon in that community.

It's not operator overloading. It's using symbols as function names. Some operators like () may have different implementations based on the Monoid instance of the underlying types, but they are based on laws which is different from say Python where >> can mean anything based on the context (even though it is used sparingly there).

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

#45
post #3

Most of these apply to other languages as well: "Haskell sucks because compilation takes too long." "Aye. And it takes too much memory too." "My major gripe with haskell was that I could never tell the space/time complexity of the my code without serious analysis (that among other things involves second-guessing the compiler's ability to optimize). This makes writing good quality code harder than it needs to be." "De…

Of course they do. The point here is exactly that all of those things apply to Haskell, simultaneously.

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

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

Haskell is too sugary; there's too many ways to write out exactly the same thing (semantically identical, not computationally). And most resources choose one way to do things over another and it all becomes fractured and difficult.

In comparison, J is all about symbols, but provide a canonical dictionary and strict semantics about how those symbols work. Still complex to learn, but easier overall.

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

#47
Haskell sucks because you can't really get anywhere before understanding monads well, and monads are (take your pick) a) too hard for most programmers, or b) too distant from the abstractions used in most programming languages.

Not that's you're done mastering Haskell when you've figured out monads, of course. There are plenty of harder abstractions running around. But monads are the orgo of Haskell, the place many earnest dreams go to die.

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

#48
I agree with the poster complaining about the wide variety of symbolic operators: readability becomes extremely important as programs grow large, and Haskell simply doesn't have it.

Lazy evaluation really doesn't pay off in my experience. Any major Haskell program turns out off for performance reasons. And when you don't, performance isn't the only problem: lazy programs often produce really inscrutable errors.

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

#49

Haskell sucks because you can't really get anywhere before understanding monads well, and monads are (take your pick) a) too hard for most programmers, or b) too distant from the abstractions used in most programming languages. Not that's you're done mastering Haskell when you've figured out monads, of course. There are plenty of harder abstractions running around. But monads are the orgo of Haskell, the place many e…

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.

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

#50
post #32
post #25

Earlier quoted context omitted.

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…

I think that your second indented block, which is currently , is supposed to be ` ` (based on the rest of your discussion).

Yes, is the general `map` (`fmap`)

   
takes function(s) out of a mappable and applies it (them) to argument(s) within a mappable.

  (+)  [1,2,3] = [add 1, add 2, add 3]

  (+)  [1,2,3]  [10, 20] = [(1 +), (2 +), (3 +)]  [10, 20] = [11, 21, 12, 22, 13, 23]

  (+)  Just 3  Just 5 = Just (3 + )  Just 5 = Just 8

  (+)  readLn  readLn = ... 
well that depends on the inputs :)
Post reply on HN