4 ms·

I'm not convinced. All abstractions are leaky, you just have to decide whether a particular abstraction is useful or not in spite of its leaks. I think the pr

I'm not convinced. All abstractions are leaky, you just have to decide whether a particular abstraction is useful or not in spite of its leaks. I think the problem you are talking about is the fact that Haskell code tends to have lots of abstractions built on top of other abstractions. While this is definitely a problem in some Haskell code bases, you will also see your fair share of Haskell code which is closer to purely functional code or closer to straightforward imperative code.

catnaroek 10y ago
> All abstractions are leaky, I can tolerate abstraction leaks when the cost of using the non-leaky version is prohibitive. For example, I wouldn't want a language that constantly reminds me that memory allocation can fail. “Memory is infinite” is just too nice an abstraction, and I'm not going to let the fact it isn't true get in the way. But I can't live with a mismatch between the language's intended and actual semantics. If the Haskell language, libraries and community promise me that Hask is morally the category of sets, then it better be morally the category of sets! Of course, this promise is impossible to fulfill in a language without a typefully delimited terminating subset, so Haskellers better scale down their ambitions to something actually realizable. > I think the problem you are talking about is the fact that Haskell code tends to have lots of abstractions built on top of other abstractions. No, I don't mind high abstraction towers - I actually like them, in fact! What I hate is climbing them down because some abstraction leaked somewhere. > you will also see your fair share of Haskell code which is closer to purely functional code or closer to straightforward imperative code. Since when is imperative code straightforward? Reasoning about purely functional programs: high school algebra, plus induction over datatypes. Reasoning about imperative programs: Hoare logic. The facts speak for themselves. In any case, this has nothing to do with functional vs. imperative. It's just “please don't impose cognitive dissonance on me!”
- dietrichepp 10y ago
  That's a really disingenuous interpretation of "straightforward". If you don't want to have a real conversation then just don't bother replying next time.
  - catnaroek 10y ago
    > If you don't want to have a real conversation I wanted to have a real conversation, but, given the hostility in your response, I'll stop.
    - dietrichepp 10y ago
      Hostility was exactly what I read in your comment about Hoare logic.
    - tome 10y ago
      I really don't know what's got into you. You've clearly got some great ideas about what's valuable in programming languages. If you took the time you spent making vague complaints about Haskell and instead spent it pointing out concrete flaws, their consequences, and how to fix them, then we'd all be much better off. I would encourage you to do that.

catnaroek 10y ago

> All abstractions are leaky, I can tolerate abstraction leaks when the cost of using the non-leaky version is prohibitive. For example, I wouldn't want a language that constantly reminds me that memory allocation can fail. “Memory is infinite” is just too nice an abstraction, and I'm not going to let the fact it isn't true get in the way. But I can't live with a mismatch between the language's intended and actual semantics. If the Haskell language, libraries and community promise me that Hask is morally the category of sets, then it better be morally the category of sets! Of course, this promise is impossible to fulfill in a language without a typefully delimited terminating subset, so Haskellers better scale down their ambitions to something actually realizable. > I think the problem you are talking about is the fact that Haskell code tends to have lots of abstractions built on top of other abstractions. No, I don't mind high abstraction towers - I actually like them, in fact! What I hate is climbing them down because some abstraction leaked somewhere. > you will also see your fair share of Haskell code which is closer to purely functional code or closer to straightforward imperative code. Since when is imperative code straightforward? Reasoning about purely functional programs: high school algebra, plus induction over datatypes. Reasoning about imperative programs: Hoare logic. The facts speak for themselves. In any case, this has nothing to do with functional vs. imperative. It's just “please don't impose cognitive dissonance on me!”

dietrichepp 10y ago
That's a really disingenuous interpretation of "straightforward". If you don't want to have a real conversation then just don't bother replying next time.
- catnaroek 10y ago
  > If you don't want to have a real conversation I wanted to have a real conversation, but, given the hostility in your response, I'll stop.
  - dietrichepp 10y ago
    Hostility was exactly what I read in your comment about Hoare logic.
  - tome 10y ago
    I really don't know what's got into you. You've clearly got some great ideas about what's valuable in programming languages. If you took the time you spent making vague complaints about Haskell and instead spent it pointing out concrete flaws, their consequences, and how to fix them, then we'd all be much better off. I would encourage you to do that.