Why does Haskell, in your opinion, suck?

https://www.reddit.com/r/haskell/comments/4f47ou/why_does_haskell_in_your_opinion_suck/

by kccqzy • 10 years ago

196 204 10 years ago

bojo3• 10 years ago

Very interesting and constructive thread. A lot of information about various Haskell warts, problems people have, and possible solutions to overcome some of them.

zzzcpan• 10 years ago

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

"Debugging boils down to wolf-fences and print-statements most of the time"

"Profiling is needed for any stack traces, and is not enabled by default, so you end up spending hours rebuilding your sandbox just to get a stack trace of an error."

"Coming from a Scala background, the tooling seems terribly cumbersome and immature. I couldn't get it to work in IntelliJ."

"You need to turn on dozens of language extensions to do pretty much anything."

"I'm a developer on a pretty large Haskell codebase, and we're in a corner of 'can't add any libraries without them conflicting with each other." Which is OK, by itself, but leads to my biggest complaint of 'why aren't API changes reflected by major/minor versioning'."

"Haskell sucks because both the standard library and the ecosystem lack guiding ideas."

YeGoblynQueenne2• 10 years ago

For those who, like me, wondered what wolf-fencing is:

"Wolf fence" algorithm: Edward Gauss described this simple but very useful and now famous algorithm in a 1982 article for communications of the ACM as follows: "There's one wolf in Alaska; how do you find it? First build a fence down the middle of the state, wait for the wolf to howl, determine which side of the fence it is on. Repeat process on that side only, until you get to the point where you can see the wolf."[10] This is implemented e.g. in the Git version control system as the command git bisect, which uses the above algorithm to determine which commit introduced a particular bug.

[https://en.wikipedia.org/wiki/Debugging]

So now you know what that thing you always end up doing is called :)

manojlds• 10 years ago

So, binary search? Why did a new name come up for this well known thing in CS?

adsofhoads• 10 years ago

What's with capturing large predators? My book on complex analysis euphemizes building a descending sequence of sets which converge to a point by

If R is the continent of Africa and we select R_n as that subregion which contains the biggest lion in Africa, we have an algorithm for capturing a big lion—we simply build a cage around point z_0.

hacker_9• 10 years ago

I think this shows that the tooling is just as important, if not more important, when choosing a language. Good debugging tools are a must simply because things always go wrong, and if I don't have an IDE that can highlight the line for me and allow to mouse hover over variable values, then the whole experience becomes a lesson in frustration.

Additionally if you expect me to 'write, build, run, repeat' just to test my code, then you better hope you have a fast compiler else I'm going to start associating using your language with the same amount of interest as watching paint dry.

marcosdumay2• 10 years ago

if I don't have an IDE that can highlight the line for me and allow to mouse hover over variable values, then the whole experience becomes a lesson in frustration.

What does that even mean in a language with no explicit model for code sequencing?

sisu• 10 years ago

This problem is significantly worse in Haskell than in most other languages. Usually you lose at most a constant factor in performance if the compiler doesn't optimize as much as you expected, but the lazy evaluation can actually change the asymptotic memory complexity. I have been bitten by lazy evaluation several times by writing code that I expect to run in constant space and then finding it require linear amount of memory because of the evaluation order.

vog4• 10 years ago

My major gripe with haskell was that I could never tell the space/time complexity of the my code without serious analysis

This is really a serious issue. The only other language where I ever had this issue was SQL. I had a project where we have lots of nested Views. We had to rephrase the SQL in sometimes very non-obvious ways, introducing intermediate Array results, CTEs, switching between sub SELECTs and JOINs -- all this just to convince the Query Planner to use a different Query Plan. That made a difference between < 1 second or a few minutes.

In the end, this is why I prefer languages OCaml or SML over Haskell. (Rust on the horizon)

Roughly speaking, in Haskell you can prove "just" correctness, while in OCaml you can prove correctness as well as performance.

revelation• 10 years ago

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

dllthomas3• 10 years ago

And yet, most of us posting these things still choose Haskell.

js85• 10 years ago

It seems to me that there is some connection/analogy with garbage collection. Garbage collection also makes reasoning about space usage of programs difficult, since it happens in some future, yet unspecified, time. Yet GC is almost always regarded as good (although historically there was a lot of fight against it), yet lazy evaluation is regarded as bad by many. Maybe the issue really is "good enough compilers"?

neutronicus2• 10 years ago

It's really easy to fuck up what will be evaluated, when, and wind up with disastrous performance ramifications.

As an example, I wanted to accumulate a list of summary data as I iterated through a recursive function. Through a coding error, the elements of the list (although not the list itself) were not evaluated until all the iterations were complete. This meant that, instead of a list of structs, which I thought I had, I had a list of zero-argument functions that, when called, would yield structs, _each of which contained a reference to a large array computed at an earlier iteration of the computation_.

So, I hemorrhaged space. This was a fuck-up, not a missed optimization.

Peaker16• 10 years ago

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

angerman• 10 years ago

Having these kinds of threads, I think, is very important for the community. On a related note, there has been quite some fallout from the haskell compilation times got worse thread, which resulted in the development of tooling around improving the situation.

tome25• 10 years ago

I agree. Thanks to everyone contributing ideas!

amelius• 10 years ago

My biggest complaint would be about incomplete documentation of GHC. Given that Haskell is a pure functional language, it should be possible to easily use any part of the compiler, and include it in your own project. However, the documentation is rather incomplete, difficult to understand, and always behind the current state of the code. That said, the scientific literature on Haskell is the complete opposite, and contains beautiful work.

Also, I'm wondering why there are so few fully compliant implementations of the internet RFCs. Such specs seem an excellent opportunity to showcase the power of functional languages, yet the implementations keep lacking.

lallysingh• 10 years ago

I haven't found a language where that isn't the case.

TheEzEzz• 10 years ago

The Roslyn C# compiler is exposed as various libraries (and is open source) and is quite nice to work with. I was able to utilize it to make a C#-to-HLSL/GLSL compiler fairly easily.

nemoniac• 10 years ago

You should check out Scheme. It has thorough documentation even including a complete formal denotational semantics.

nickpsecurity2• 10 years ago

Oberon... maybe VLISP Scheme.

POSIXprog2• 10 years ago

Bryan Cantrill's take: https://youtu.be/0T2XFSALOaU?t=2021

My answer would be lazy evaluation by default. It's extremely unusual, and I've never seen a convincing enough justification for it, and it gives rise to performance bugs (space leaks) that can be fiendishly difficult to track down and fix and are disastrous in production. With the arrival of Idris, I think we can pretty conclusively say this was a mistake and that the Miranda branch of the PL family tree is likely to prove to be an evolutionary dead-end.

Tyr42• 10 years ago

My perspective on this is that lazy be default made sticking to purity much more compelling as if you just dropped print statements in you weren't sure exactly when they get evaluated. This lead to important developments like IO (they started with user input just being a lazy list! Very possible to accidentally block trying to read too much), which might not have happened otherwise.

But now, I do feel like lazy is best kept for core data-structures and places where you know you can use it, and a strict by default variant of Haskell would be better, now that we have learned most of the lessens from lazyness.

oldmanmike4• 10 years ago

"My perspective on this is that lazy be default made sticking to purity much more compelling as if you just dropped print statements in you weren't sure exactly when they get evaluated."

And that's basically a death sentence to the feature because it reduces it to a silver lining of desperate post-mortem optimism. As far as my understanding goes, lazy evaluation was originally included in the language because it was perceived to be a powerful optimization technique enabled by pure functional programming. You reduce the amount of work a program is doing dynamically at runtime while not trading off on readability or modularity. All win. Except there were subtle trade-offs that have made themselves clear over the years and like you said, most would agree that lazy-by-default is too extreme of a feature and doesn't really pay its share of the rent at the end of the day.

My main gripe with lazy evaluation is that it's implicit behavior. It's to evaluation what garbage collection is to memory or dynamic types are to types. It hides something from the programmer that is useful to know more often than not.

tene• 10 years ago

a strict by default variant of Haskell would be better

https://ghc.haskell.org/trac/ghc/wiki/StrictPragma is coming in GHC 8.

YeGoblynQueenne2• 10 years ago

> Haskell sucks because both the standard library and the ecosystem lack guiding ideas. The former often feels like it is an amalgamation of PHD theses that have been abandoned soon after being complete.

That's a bit on the nose. [1]

[1] As in "ouch".

Findeton2• 10 years ago

I just prefer to use languages without a Garbage Collector.

hkjgkjy• 10 years ago

Any experience doing functional programming without garbage collector?

I'm doing a lot of Clojure, and can't really see how it would be a pleasant experience without GC but curious to hear any interesting thoughts.

Findeton2• 10 years ago

The closest I've tried is Rust, which is not 100% functional or 100% anything but I like it.

qb45• 10 years ago

ATS claims to support memory safe functional programming without GC. I never used this language, though.

IIRC the idea is that allocating memory or writing something through a pointer returns a magic "cookie" value which certifies that the pointer now points to a block of certain size or data of certain type. This cookie can be bound to a variable like any other value and passed to other code together with the pointer so that the code can know that it's safe to access the pointer.

There are rules - cookies can't be pulled out of thin air or cloned, have to be destroyed during deallocation, etc. All of this is checked during compilation and removed from the final executable.

http://www.ats-lang.org/

astrange• 10 years ago

Swift is a language with many functional features and no GC. As long as you don't mind breaking cycles yourself, it's fine.

pjmlp5• 10 years ago

And spend time tracking down memory corruption?

iopq2• 10 years ago

Rust doesn't require you to track down memory corruption in safe code.

Peaker16• 10 years ago

Having done a lot of C code without dynamic memory allocations at all -- chasing memory corruption was a thing, but a rare thing. I spent more time chasing performance issues and tuning GC in some projects than I did chasing memory corruption in my C projects.

njharman2• 10 years ago

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.

Peaker16• 10 years ago

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.

Sanddancer• 10 years ago

Memory management isn't solved though. In a lot of applications, it takes up a significant amount of memory and/or cpu time, which can be of importance if you have time constraints, space constraints, and/or power constraints. Deterministic memory lets you, for example, know that the 256 bytes on your microcontroller is more than enough, or that you will always hit the timings needed to guarantee that your project will always output at 60 frames per second. Yes, there are a lot of times you can just throw RAM at the problem to make it go away, but there are a lot of really interesting problems out there that do require you to be able to intimately manage resources.

pmarreck• 10 years ago

I can tolerate it in Elixir/Erlang because GC is per-process-id (of which there could be dozens or hundreds in a typical Erlang/Elixir app) and not remotely a global world stopper.

akavel4• 10 years ago

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 and sad emptiness. And I don't even know how to google any one of them. Don't know how to solve this for myself. I've once found a list of suggested names for some common ones, but - I don't like having to learn all that by heart before I even start with the language; and also I feel pretty certain those are not all, and many libraries seem to like to invent their own new ones, so back to square one.

That's I believe the main reason I find SML more attractive: it seems to use operators to a much, much lesser extent, apparently preferring alphanumeric function names in the core, and in 3rdparty libraries too.

jgallag8• 10 years ago

Hoogle could help with the searching problem: https://www.haskell.org/hoogle/

akavel4• 10 years ago

Nice to know. Still, no spelling there, as far I can see. And no docs or examples either, apparently: https://www.haskell.org/hoogle/?hoogle=%3E%3E%3D is still a problem for me

bojo3• 10 years ago

It can be overwhelming, and trying to use Google is terrible. There's a really nice Haskell specific search engine though: https://www.haskell.org/hoogle/ - you can query module/function names, type signatures, etc.

A lot of these weird "operators" are also typically defined with a synonymous named function. These types of operators are usually functions after all, not actual language operators.

sid-kap2• 10 years ago

Check out Hayoo (http://hayoo.fh-wedel.de/) -- I like it more than Hoogle

wirrbel3• 10 years ago

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,3]`. This makes mapping as easy as a normal function call (and the operator name `<$>` was not choosen arbitrarily. `$` by itsself is the function application operator, so `f $ 3` does on a single element, what `f <$> x` maps over an instance of Functor.

With applicatives, the pattern of

    f <$> a <*> b <*> c

is very common (with a type signature

    f :: a -> b -> c -> ....

JadeNB• 10 years ago

I think that your second indented block, which is currently

<*>

, is supposed to be `<$>` (based on the rest of your discussion).

akavel4• 10 years ago

Now that is the first time I see an explanation which tries to point out some sense in the apparent madness. Appreciated! Would you or someone else knowledgeable be willing to create a guide like this, but spanning all the magic runic incantations known to Haskell wizards? Showing similarities, analogies, etc? And targeted at dumb apprentices like me? I'd be happy to serve as a somewhat (though not perfectly) dumb specimen to bounce explanation attempts off! (email in my profile - just added, in case someone was crazy enough to try to pull that off)

davesque2• 10 years ago

It's nice that someone was trying to make things sensible. But what are the precedences of those operators? Maybe you would argue that you can expect them to be whatever makes the most sense. But what about the one case when they aren't what you expect and you're getting some confusing error (or, gasp, incorrect runtime behavior). Maybe a library designer made a bad decision about which precedence to give to a certain operator. Or maybe the choice was simply not so obvious.

I guess the solution is just to put parentheses everywhere, but why is it that, whenever I show people code where I'm doing that, they always point out "Oh, you don't need parentheses there." I feel like that just goes to show that the community underestimates the confusion most people feel when they encounter a jumble of custom operators and have to recall to themselves which parts of an expression are evaluated first or even in what direction. This language feature feels more like an antipattern.

I really think the benefits of making operators so easy to define are quickly outweighed by the drawbacks for most programmers. The infix culture seems like one of the biggest barriers for this language.

pandaman• 10 years ago

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.

sillysaurus33• 10 years ago

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. (And it's worth doing.)

iak8god• 10 years ago

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

webnrrd2k• 10 years ago

Also, read as: "add one and two"

duaneb• 10 years ago

Precedence is easier to parse with prefix/sexp/stack notation than infix.

douche• 10 years ago

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.

ch0wn• 10 years ago

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

stepvhen• 10 years ago

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.

dllthomas3• 10 years ago

If you find yourself needing to read Haskell, feel free to ask others how they pronounce things.

rntz• 10 years ago

And I don't even know how to google any one of them. Don't know how to solve this for myself.

https://www.haskell.org/hoogle/ lets you search for functions by name, including symbol-named functions like <$> and co.

(You can also search for functions by type, which is a pretty cool feature, but not what you were asking for.)

userbinator• 10 years ago

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 reads to me like a giant run-on sentence where you need to make much greater use of context in parsing.

I suppose the other extreme is Lisp, which I've played around with and found quite pleasant because of its very unambiguous syntax.

tome25• 10 years ago

I agree that Haskell library writers can assume too much knowledge of operator precedence on the part of their readers. It can often make it very hard to read unfamiliar code.

Peaker16• 10 years ago

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.

dllthomas3• 10 years ago

Haskell does seperate list items (and tuple elements, and record member assignments) with commas.

You are, of course, free to object to the lack of separators between (and parentheses around) function arguments. I find it pretty natural when everything is curried.

tome25• 10 years ago

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?

skybrian• 10 years ago

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

neutronicus2• 10 years ago

As a counterpoint, I love this about Haskell.

It seems like my ability to hold logic in my head is partly visuo-spatial, and the terseness makes it easier for me to tell what's going on. (I also do Scientific Computing, so a general resemblance to mathematical notation is hugely helpful for me reading code).

ajuc2• 10 years ago

I think similarly (I sometimes write code like this

  let A be sth
      X be sth else, ...

and then the equations and predicates and pseudocode using one-letter names). Then I change these to regular variable names of course (my friends don't think it's readable).

I also really like the fact that in clojure identifiers can use math symbols exactly for this reason. I love the fact that + is a regular function, that I don't have to wrap it to reduce or map with it, and don't have to remember how to turn it from infix to prefix or vice-versa. That it works with any number of arguments. Same with <, >, =.

This the prettiest definition of dot product I've seen in any programming language

    (reduce + (map * v1 v2))

It's great because with 2 very universal language constructs you get to express tons of stuff cleanly. There's no incidental complexity there.

But I just can't force myself to like Haskell operator-happy style. I've tried learning Haskell a few times, and never sticked to it for more than a week, because operators everywhere just make my uneasy, and there's too much specialized version of functions.

I tried to learn common lisp a few times before clojure and nvere managed to get through the weird historical naming nonsense. Haskell sometimes feels like common lisp in that respect.

pjc50• 10 years ago

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.

Schoon• 10 years ago

If you are ever confronted with a non-trivial parsing problem, have a look at Haskell again and use Attoparsec. <$>, <>, >, <*, <|> will become incredible concise tools for expressing your ideas!

bernalex• 10 years ago

Hallo. I see some of you are listing things here. It really would be very helpful to me if you could list them on Reddit as well, using the format of the thread, so that I only have one source to deal with.

I don't mean to instigate any Reddit vs. Hacker News rivalry, or whatever, but I just don't have time to go over several sources for my talk and PDF. So this is just a tip for if you want me to include your Haskell "complaint".

Glad to see the thread has sparked discussion here too!

shmageggy• 10 years ago

You already have this page open... how much more time is needed?

arianvanp• 10 years ago

Because it avoids duplicates. The idea is that we have one place where all the problems reside, and where the problems are sorted by upvote count.

virmundi3• 10 years ago

Mine is that it's built on a lie. A nobel lie, but a lie none the less. In order to be pure it has "stop the world and record it" with monads to do any IO. It pretends that the world can be snapped shotted and immutable. In reality the monad is only an extra box with a belief that the world stops. The world in fact does not.

tome25• 10 years ago

Nope, that's not what it is at all. IO is "just" an effect tag.

eveningcoffee• 10 years ago

Well, you can argue that you at the given moment are not the same you a moment ago.

You can perceive yourself moment ago exactly because of that.

Others who have not seen you recently hold the old reference to you.

I would rather say that the world is naturally immutable.

solidsnack90003• 10 years ago

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

virmundi3• 10 years ago

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.

oldmanmike4• 10 years ago

In order to be pure it has "stop the world and record it" with monads to do any IO.

That's not how IO in Haskell works, you're basically describing what Haskell would be if it literally had no side-effects ever.

johan_larson2• 10 years ago

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.

devishard2• 10 years ago

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.

pron17• 10 years ago

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 computations are not quite functions (they are processes that compute functions), and while the approximation works well enough much of the time, some things require recapturing the more accurate definition of computations as continuations (i.e. a computation can block and then resume). If your language does not have continuations, only functions, monads achieve the same thing. If, OTOH, your language has continuations (as most non-pure languages do, although most don't have reified continuations, which are just as "programmable" as monads only more composable), monads don't really help.

See http://blog.paralleluniverse.co/2015/08/07/scoped-continuati...

tinco• 10 years ago

I don't feel at all that this is true. It is not necessary to understand monads to get good work done in Haskell for basically any purpose. Authoring monads is something usually left to library authors, and for basic users it's just a nifty interface that lets you do handy things in imperative style haskell ('do' syntax).

I don't want to be defensive in this thread, since obviously getting real about deficiencies in Haskell is a great way of making a path for positive change, but the spreading of the idea that monads are magical and hard is dangerous.

It's similar to how back in the day Java and PHP developers dismissed Ruby on Rails for being magical and hard to understand with weird syntax. The truth is that Ruby on Rails was very easy to use regardless of its rather complex innards, and once you get a good handle on Ruby, even the Rails innards weren't all that difficult to understand and extend.

The hard part of learning Haskell is getting to grips with functional style programming and understanding the power of its type system. Learning that is rewarding and has a low entry-barrier, it's even something I'd recommend to someone who has never programmed before. Don't worry about monads.

p4wnc6• 10 years ago

Most people writing Haskell code for real problems should never write their own instances of Monad. When you see someone implementing tons of instances of Monad, it's a sign of over-engineering and Haskell masturbation. Very, very few people are good enough to judiciously understand when and where to write their own instances.

In the majority of cases you should merely be using instances of Monad which solve extremely common problems, like Maybe, List, State, Reader, Writer, and sometimes "functions of a common argument" `((->) r)`. The function one is perhaps the trickiest to understand.

For these examples of Monad, it's really not much work to learn how to apply them. Even just reading LYAH gets you pretty far. You could almost just pretend it is a DSL for composing units of work in each of the classic problems that motivate them (e.g. passing stateful computing, doing non-deterministic computation on a list, etc.).

But I do agree this becomes a huge problem when you join a team and they've architected skyscrapers of customized Monads to do routine stuff. That's a very poor way to build systems in Haskell unless you can guarantee every person on the team is a Haskell expert (hint: you can't).

Your comment strikes me more as a downside of the oneupsmanship of the Haskell community than a problem with Haskell itself.

whateveracct2• 10 years ago

Most people writing Haskell code for real problems should never write their own instances of Monad.

Does using Free count? ;)

whateveracct2• 10 years ago

Understanding monads sufficiently to work in monadic production code requires two things:

- Learning the type signatures of all the primitives of the Functor/Applicative/Monad hierarchy.

- Seeing some common monadic types in action. Basically understand how to interpret the "context" of M[A] and the semantics of bind. So Option[A] is a potentially missing A and bind short circuits. Writer[W, A] is an A with some accumulated W and bind accumulates the W. IO[A] is a description of an IO action that, when run, will yield an A and bind will create a new IO action that will use the result to produce a new IO action.

devishard2• 10 years ago

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.

denim_chicken2• 10 years ago

Haskell sucks because mutability and strictness are extremely important for writing large complex programs, and Haskell deliberately makes both of these things inconvenient.

Also, Haskell's ecosystem and tooling is still crappy, probably because writing complex programs in Haskell needlessly difficult (due to laziness and immutability).

And the "type-safety" guarantees are a red herring. They are not that useful in practice.

tome25• 10 years ago

Haskell sucks because mutability and strictness are extremely important for writing large complex programs, and Haskell deliberately makes both of these things inconvenient.

That's funny, because I'd say that immutability is essential for writing large on complex programs.

Strictness, on the other hand, hmm, I can take it or leave it.

Haskell's ecosystem and tooling is still crappy

No argument here.

because writing complex programs in Haskell needlessly difficult

Argument here :)

And the "type-safety" guarantees are a red herring. They are not that useful in practice.

I've found the opposite. Type safety has saved me so many headaches I'm never going back.

denim_chicken2• 10 years ago

Well, I can't say much other than that I encourage everyone to try Haskell for themselves and form their own opinion -- if they can find the time to get over the language's extremely steep learning curve.

darksaints• 10 years ago

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 teammate is gonna come in and rewrite everything you just wrote so he can feel happy with it too. And then lecture you about how lenses are wonderful and how you need to learn the principle of least power.

Biggest community problem: a small minority of extremely obnoxious and toxic assholes. They raid other communities and make fun of their languages and members. 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.

tome25• 10 years ago

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. Contact details here: http://web.jaguarpaw.co.uk/~tom/contact/

nv-vn• 10 years ago

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.

guard-of-terra• 10 years ago

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 the channel from under its original founder and banning him.

On #haskell, you would be immersed in polite chat revealing the development in all things FP, plus even pretty stupid questions were answered in such way that they enlightened both the asking person and bywatchers.

Also they had quite a few awesome bots that let anyone practically develop directly in IRC.

pekk2• 10 years ago

To be fair it doesn't make a lot of sense to march into #java for the purpose of bitching about how you don't like java. That's just trolling.

ethagnawl• 10 years ago

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.

js85• 10 years ago

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 evaluation. I thought the whole point of Haskell was to lazily create a "recipe" as an IO monad, which will then be evaluated after it is returned from function main. In particular, I wonder how Idris deals with this problem, as I read it has strict evaluation.

Peaker16• 10 years ago

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.

tome25• 10 years ago

the whole point of Haskell was to lazily create a "recipe" s an IO monad

This "recipe" explanation is one way of explaining how you can think of IO in an impure language. I do wonder if we've taken that explanation too far. I'm pretty sure nobody thinks of it like then when they're actually coding.

T-R3• 10 years ago

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/java and harassing people. I feel pretty strongly that the opposite is a more common problem, though, particularly on HN: the anti-intellectualism against functional programmers, and Haskell users in particular, is rampant and gets pretty offensive. Example off the top of my head - https://news.ycombinator.com/item?id=10527745 - article simply explaining a math concept gets, as what was the top comment at the time, a condescending comment calling it all "mental masturbation". I've stopped reading HN so much because it's pretty clear that people trying to learn abstract algebra and apply it to code aren't welcome here.

striking• 10 years ago

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

tome25• 10 years ago

Can I encourage everybody to classify their complaints according to the following scheme?

http://h2.jaguarpaw.co.uk/posts/complaining-about-languages/

I believe it would help everybody understand how we can improve people's experience around Haskell.

pekk2• 10 years ago

These are all interacting parts which make up a system. You can't separate the parts out so cleanly when they have so many interactions.

tome25• 10 years ago

Care to give some examples?

Some examples which from my point of view seem pretty clear cut:

Laziness and purity fall squarely under "language specification". There's no way of seeing them as a problem with libraries or community.

'I think a lot of the Haskell community is obsessed with mathematical "cuteness", which basically they take to mean "infix-operator-heavy" notation.' is a problem of community (and arguably language specification), certainly not of tooling or infrastructure.

"String should not be [Char]" is a problem with libraries (and arguably specification). Certainly not community or tooling.

johan_larson2• 10 years ago

What's the difference between "infrastructure" and "tooling" in this context?

tlogan• 10 years ago

I had chance to debug one tool built using Haskell. I was amazed how Haskell solution for clean and easy to understand (it was a parsing library generating better optimized SQL queries).

The main problems are:

- it is hard to find examples/snippets of real-world solutions on net (majority of examples are like Hello world and these examples are not useful)

- lack of documentation about building real-world solutions

Maybe more work should be done in explaining how Haskell can be used to solve some real-world problems. Parsing seems like place where Haskell shines and more examples should be available.

So maybe just focus on "parsing with Haskell" and win that space.

taktoa• 10 years ago

You may be interested in the State of the Haskell Ecosystem [1] and School of Haskell [2].

[1] https://github.com/Gabriel439/post-rfc/blob/master/sotu.md

[2] https://www.schoolofhaskell.com

olavk• 10 years ago

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.

PeCaN• 10 years ago

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.

oldmanmike4• 10 years ago

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 instance. This just seems to be a problem of high-level programming languages in general, they're really slow until you start optimizing them at compile-time. And with each one of those optimizations, you get another layer of indirection with regards to how disconnected the speed of the code you wrote should be vs. how fast the final product actually is. Haskell has no business being as fast as it is already, but GHC gives it to us at the price of long compile times and very fuzzy performance properties that are very finicky and expert-friendly.

The problem I see here is just the unsolved computer science problem of how to reduce the complicated, drawn-out, and error-prone job of a C programmer into the succinct job of a functional programmer without fundamentally pretending modern computers work in a way they don't.

nickpsecurity2• 10 years ago

The complain list on Ocaml is almost always smaller than on Haskell. It might be easier to just fix Ocaml's issues and use it. If not permanently over Haskell, then temporarily until Haskell can get their more complex issues solved.

T-R3• 10 years ago

I think that's changing. A lot of the over-proliferation of operators came from missing functions (like Data.Function.(&)), missing typeclasses (Like with Data.Lens or other generic operators), or missing sugar (like Applicative Do or Idris' bang notation).There's definitely some cleanup work since the ecosystem's changed so much, though.

Peaker16• 10 years ago

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.

seagreen• 10 years ago

I think Haskell is optimized for _rewriting_ code. Personally, I think this is far more important than reading code!

Being able to read code is great (e.g. Python), but if you can't change things without fear the natural tendency of the codebase won't be in a good direction.

Haskell can actually take a while on the first write, but once you have the rails of the type system down it's sooooo easy to change things, even in a codebase you're new to or haven't touched in a while.

malisper• 10 years ago

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.

tome25• 10 years ago

The non-primed versions simply shouldn't exist (everyone agrees) and in my opinion the 1 versions shouldn't exist either. This takes 8 down to 2, and they are genuinely two different functions so both need to exist.

Peaker16• 10 years ago

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.

yongjik• 10 years ago

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 and why it's rejecting my code.

Put another way, C++ allows me to try "quick and dirty" solutions first, and then later iterate and improve. Haskell requires me to be perfect at first try.

Peaker16• 10 years ago

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.

ufo• 10 years ago

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 :)

kccqzy• 10 years ago

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.

davesque2• 10 years ago

My main gripe is that the syntax is too sugary. I've often wondered to myself what a Haskell with syntax more in the spirit of Python would look like. I just wish I didn't always feel like I had to literally memorize what various custom operators meant with flashcards or something. Also, Haskell has relatively complex parsing and evaluation rules. The meaning of well-written code shouldn't be obscured by syntax.

And, along the lines of the syntax, the culture of style in Haskell. Single letter variables abound. Not just throwaway vars where the meaning is pretty clear from context. Entire libraries written with only single letter or acronymic variable names. Good luck understanding what a library author was trying to do by reading their code. I think this culture problem is largely being driven by the fact (which I mentioned) that Haskell's base syntax is already very opaque. I understand that the language takes some cues from the mathematical community (not surprising given its history). However, the language needs to ditch this to gain broader acceptance.

And, again, leading into my next point: the culture of the community in general is too academic. I'll make another comparison with Python. The Python community, among scripting languages, leans more toward the academic side but in a good way. They've found a nice balance. It's easy to get started and, if you want to learn more about the details, you can do so. With Haskell, you immediately get hung up on the details. Most of the details have to do with how Haskell fits into the framework of category theory. However, most programmers don't give a shit about provability. They just want to write software that is faster, safer, and more concise without being terse. I'm not convinced that it's impossible to have this in a functional language with the same goals as Haskell. Beginners should be able to get started quickly and without much confusion. If they're curious about the underlying principles, they should be able to gradually peel back the layers and learn more.

alectheriault• 10 years ago

To everyone complaining about laziness, the new GHC 8.0 compiler (due to be released any day now) has a ['Strict' pragma option][1].

[1] https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

tome25• 10 years ago

Unfortunately (?) this doesn't really make Haskell a strict language.

Tinned_Tuna• 10 years ago

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.

Why does Haskell, in your opinion, suck?

Related Stories