5 ms·

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

by zzzcpan 11y 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."

YeGoblynQueenne 11y 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 https://en.wikipedia.org/wiki/Debugging] So now you know what that thing you always end up doing is called :)
- manojlds 11y ago
  So, binary search? Why did a new name come up for this well known thing in CS?
  - vog 11y ago
    Bisection is also a well-known term, in mathematics as well as computer science.
  - tedmiston 11y ago
    Wolf fencing is new to me too. It seems to be used only in the context of debugging. While with git bisect, we are also repeatedly ~halving the remaining search space, the list of commits isn't "sorted" like the precondition for binary search. You could argue that commits are sorted against time. But I would say that's different because we don't know which commit hash we're looking for -- we just want to find the point in time when our code stopped working, not that I've ever had to use it before ;).
    - vog 11y ago
      *> the list of commits isn't "sorted" like the precondition for binary search. Good point. One may think that in some sense, it is sorted: The history is sorted into "good" commits (before the bug was introduced), which are followed by "bad" commits (after the bug was introduced). However, the bisection algorithm also works if "good" and "bad" commits are mixed. Even then it will find one commit where the bug was introduced (although there may be other places where it had been fixed and later reintroduced). This works because bisection doesn't require a sorted list, it just needs a continuous function. And any sequence is just a special case of that.
      - x1798DE 11y ago
        > However, the bisection algorithm also works if "good" and "bad" commits are mixed. Even then it will find one commit where the bug was introduced (although there may be other places where it had been fixed and later reintroduced). I don't understand this comment. Need for sorting the list is essentially the same in both cases, because "the bug was reintroduced" is essentially equivalent to "a lower number showed up later". A binary search makes the assumption of sorting because it's premised on the idea, "Whatever number I find, every number that comes after it will be larger". Same with bug-finding in a git history, it assumes "If I find a point in the history where the problematic behavior exists, it exists at all points after that for the same reason." If you had an "unsorted" history where a bug was fixed and then reintroduced in another way, your binary search may fail to find the immediate cause of your problems in the same way that an "unsorted" binary search would fail to find what it's looking for.
- adsofhoads 11y 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 11y 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.
- marcosdumay 11y 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?
  - nightski 11y ago
    Well Haskell has a well defined execution order. I think the large problem is that compiled Haskell doesn't represent the original source at all making this tricky if not impossible.
    - marcosdumay 11y ago
      The execution order is only defined on the IO monad or when there is data dependency. Independent chunks of pure code can be executed in any order.
      - deleted 11y ago
        [deleted]
      - nightski 11y ago
        The key word being independent. There is still a natural baked in dependency ordering. That is all that I meant. I realize I could of phrased it better.
sisu 11y ago
"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." 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.
vog 11y 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 11y ago
Of course they do. The point here is exactly that all of those things apply to Haskell, simultaneously.
- dllthomas 11y ago
  And yet, most of us posting these things still choose Haskell.
js8 11y ago
"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 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"?
- neutronicus 11y 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.
- Peaker 11y ago
  It is similar to garbage collection, but maybe an order of magnitude worse. The benefits of lazy evaluation are also very nice, though.

by zzzcpan 11y ago

YeGoblynQueenne 11y 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 https://en.wikipedia.org/wiki/Debugging] So now you know what that thing you always end up doing is called :)

manojlds 11y ago
So, binary search? Why did a new name come up for this well known thing in CS?
- vog 11y ago
  Bisection is also a well-known term, in mathematics as well as computer science.
- tedmiston 11y ago
  Wolf fencing is new to me too. It seems to be used only in the context of debugging. While with git bisect, we are also repeatedly ~halving the remaining search space, the list of commits isn't "sorted" like the precondition for binary search. You could argue that commits are sorted against time. But I would say that's different because we don't know which commit hash we're looking for -- we just want to find the point in time when our code stopped working, not that I've ever had to use it before ;).
  - vog 11y ago
    *> the list of commits isn't "sorted" like the precondition for binary search. Good point. One may think that in some sense, it is sorted: The history is sorted into "good" commits (before the bug was introduced), which are followed by "bad" commits (after the bug was introduced). However, the bisection algorithm also works if "good" and "bad" commits are mixed. Even then it will find one commit where the bug was introduced (although there may be other places where it had been fixed and later reintroduced). This works because bisection doesn't require a sorted list, it just needs a continuous function. And any sequence is just a special case of that.
    - x1798DE 11y ago
      > However, the bisection algorithm also works if "good" and "bad" commits are mixed. Even then it will find one commit where the bug was introduced (although there may be other places where it had been fixed and later reintroduced). I don't understand this comment. Need for sorting the list is essentially the same in both cases, because "the bug was reintroduced" is essentially equivalent to "a lower number showed up later". A binary search makes the assumption of sorting because it's premised on the idea, "Whatever number I find, every number that comes after it will be larger". Same with bug-finding in a git history, it assumes "If I find a point in the history where the problematic behavior exists, it exists at all points after that for the same reason." If you had an "unsorted" history where a bug was fixed and then reintroduced in another way, your binary search may fail to find the immediate cause of your problems in the same way that an "unsorted" binary search would fail to find what it's looking for.
adsofhoads 11y 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 11y 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.

marcosdumay 11y 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?
- nightski 11y ago
  Well Haskell has a well defined execution order. I think the large problem is that compiled Haskell doesn't represent the original source at all making this tricky if not impossible.
  - marcosdumay 11y ago
    The execution order is only defined on the IO monad or when there is data dependency. Independent chunks of pure code can be executed in any order.
    - deleted 11y ago
      [deleted]
    - nightski 11y ago
      The key word being independent. There is still a natural baked in dependency ordering. That is all that I meant. I realize I could of phrased it better.

sisu 11y ago

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

vog 11y 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 11y ago

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

dllthomas 11y ago
And yet, most of us posting these things still choose Haskell.

js8 11y ago

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

neutronicus 11y 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.
Peaker 11y ago
It is similar to garbage collection, but maybe an order of magnitude worse. The benefits of lazy evaluation are also very nice, though.