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

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

#121

Post by Peaker » Sun, Apr 17, 2016, 8:37 PM UTC

userbinator wrote: post #66

akavel wrote: 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…

The "separatorless" style is also another aspect of the syntax that's turned me off Haskell --- most other languages have characters like ';' that serve to delimit statements, ',' to separate list elements, and ample use of parentheses to clarify how things should be parsed (e.g. identifier followed by '(' signals "function call", and the matching one signals the end of the argument list.) In comparison, Haskell code…

In recent years, I've switched to a Haskell style that is much more "separator-ful". I chain my computations together using the `&`, `` and `>>=` operators. These operators are flipped function application, flipped fmap, and bind.

They are all declared as left-associative with precedence 1, which means that they read left-to-right. i.e: they're the separators, so you don't need extra parenthesis.

So you can have something like:

  employees database
   salary
  & sum
  & writeReport title
  >>= sendReport destination

This lets you read your data processing pipe-line, while also seeing what kind of effects are being composed together at each step.

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

#122

Post by Peaker » Sun, Apr 17, 2016, 8:42 PM UTC

js8 wrote: post #77

darksaints wrote: post #57

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…

> 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 action "print the number N" (for varying N). Evaluating this list doesn't cause printing. Now if you use:

  let y = sequence_ x :: IO ()

You now have another pure value, y, which represents the action to print all the values from 1 to 10. Evaluating y still doesn't cause anything to happen.

main = y

NOW you've actually scheduled the effect denoted by 'y' to execute.

In other words, main is assigned a composition of effects, that by virtue of being inside main, will get executed. This has nothing to do with evaluation order, and when or how these effect descriptions got evaluated.

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

#123

Post by Peaker » Sun, Apr 17, 2016, 8:45 PM UTC

js8 wrote: post #83

zzzcpan wrote: 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…

"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." It seems to me that there is some connection/analogy with garbage collection. Garbage collection also makes reasoning about space usage of progr…

It is similar to garbage collection, but maybe an order of magnitude worse. The benefits of lazy evaluation are also very nice, though.

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

#124

Post by ethagnawl » Sun, Apr 17, 2016, 8:45 PM UTC

guard-of-terra wrote: post #74

darksaints wrote: post #57

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…

In my opinion, Haskell community was very warm and helpful, and also able to admit shortcomings. This was before Stack Overflow reshaped the landscape. On Freenode, ##java was a pretty hostile place (having to deal with people asking to do homework for them or being overall clueless) with attitude "if you see a problem with Java, the problem is you". The culture was so toxic that "forces of evil" ended up stealing th…

> In my opinion, Haskell community was very warm and helpful, and also able to admit shortcomings.

I just wanted to second this. On a whim, I started attending various community events in/around NYC a few years ago, knowing next to nothing about the language, and found _everyone_ (no exaggeration) I interacted with, saw present, etc. to be welcoming, helpful and encouraging.

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

#125

Post by Peaker » Sun, Apr 17, 2016, 8:52 PM UTC

malisper wrote: post #93

My reason is that there are eight different folding functions: foldl, foldr, foldl1, foldr1, foldl', foldr', foldl1', and foldr1'. There are twelve if you count: scanl, scanr, scanl1, scanr1. Also, the implementation of monad transformers is disgusting. It requires O(n^2) code generation where n is the number of monads.

Folds can be left-associative or right-associative. (l or r suffix).

Folds can be eager or lazy (prime suffix for eager).

Folds can work with at least 1 element to avoid the empty case ('1' suffix) (e.g: a function like `maximum`).

This gives 2^3 cartesian space of folds. Each and every one may be useful in some cases. For ordinary lists, though, foldr and foldl' cover virtually all uses (just use 'error' for the empty case when you need to).

Monad transformers don't require O(n^2) anything. You're talking about the 'mtl' package on top of the 'transformers' package. The 'transformers' package is useful on its own and doesn't have this problem.

The 'mtl' automatic lifter framework does require something in the order of O(n^2) instances (for n=6 or so). However, this is not really just 6 copies of the same code over and over. The threading of monadic state through different monads varies. For example: `Reader.local` is implemented very differently for `WriterT` and for `ContT`. So there really are in the order of O(n^2) different interactions to write code to account for.

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

#126

Post by Peaker » Sun, Apr 17, 2016, 8:55 PM 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…

When you gain experience in both C++ and Haskell, the time you spend debugging runtime errors in C++ diminishes somewhat. But the time you spend debugging type errors in Haskell diminishes to almost nil.

Experience and practice makes perfect -- debugging a type error becomes easy. Maintaining a large C++ application and changing something is more scary (even for the expert) than changing something in a large Haskell program.

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

#127

Post by Peaker » Sun, Apr 17, 2016, 9:00 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…

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 Haskell special and powerful compared to other languages. You have to explicitly opt out of these restrictions - making the majority of code easier to reason about, simply because there is so much it cannot do.

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

#128

Post by Peaker » Sun, Apr 17, 2016, 9:02 PM UTC

olavk wrote: post #87

Haskell, like Perl, is optimized towards writing code rather than reading code. I would like a language which is to Haskell what Python is to Perl.

I disagree.

Haskell, like Perl, gives users more freedom to express themselves than other languages.

Unlike Perl, many (most?) Haskell features are oriented towards ease of statically understanding programs without executing them. Haskell culture is much about reasoning power around Haskell programs.

Reasoning about programs is the ability to read code in depth.

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

#129

Post by pjc50 » Sun, Apr 17, 2016, 9:04 PM UTC

akavel wrote: 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 suspect this is due to its mathematician-heavy user base, who are very used to just defining new operators with a squiggle on the blackboard. The worst language for this was APL, where most of the common operators could not be typed on a normal keyboard.

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

#130

Post by Peaker » Sun, Apr 17, 2016, 9:06 PM UTC

njharman wrote: post #58

Findeton wrote: post #14

I just prefer to use languages without a Garbage Collector.

Man! I'd never want to code in language that forces me to manage memory. A boring, solved problem the compiler/run time should handle for me.

I enjoy both kinds of languages.

I do think garbage collectors are overrated.

When using certain styles in C or C++, memory management is really a tiny aspect you have to spend a tiny minority of your time thinking about -- but you gain so much determinism of execution in return.

I've been burnt by garbage collection killing my programs' performance many times -- having to tune the garbage collector has taken more time than just writing manual memory management in some cases!

Also, dynamic memory allocation and garbage collection just injects so much dynamism and uncertainty in your program's execution. I dislike it for the same reason I dislike dynamic typing. I want to be able to statically reason about the resource use of my program, just like I want to statically reason about any other aspect of my program.