5 ms·

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 ef

by Peaker 10y ago

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.

pron 10y ago
> It's the taking away of non-pure primitives and libraries -- and replacing those with type-labeled effects. PFP and typing are quite orthogonal. You can have effect systems in non-PFP, continuation-based languages (i.e. languages that don't equate computations with functions). You can have non-pure, non-monad-based type-labeled effects. > Haskell gains power in its framework for restricting code. Sure, but Haskell does this within a very specific design, based on extensional functional semantics. There are other ways of restricting what code can or cannot do that don't have the same semantics. Personally, I think that various effect systems may hold promise and are certainly interesting enough to try, but the PFP abstraction has so far failed to yield results commensurate with its cost.
- Peaker 10y ago
  > PFP and typing are quite orthogonal They are orthogonal in 1 technical sense. But the benefits are reaped from the combination. > the PFP abstraction has so far failed to yield results commensurate with its cost. You say this based on what? Me and other Haskell users believe that the costs are very minimal and the benefits are quite huge.
  - pron 10y ago
    > But the benefits are reaped from the combination. Well, I happen to think that some forms of rich typing are quite beneficial, but that value-semantics is a negative. I don't see Haskell having any tangible benefits whatsoever over, say, OCaml (other than ecosystem-related stuff), which has one (relatively rich typing) but not the other (PFP). > You say this based on what? Based on the fact that the few Haskell shops out there -- despite them being composed of avid enthusiasts and people who devote a lot of thought into the Haskell way of thinking, are not reporting even 2x productivity gains (although I don't know what huge means to you). I mean, some say they feel those gains, but when you look at iteration speed, time to market etc., you see negligible advantage if at all. As to the cost, I won't argue with you, but I encourage people who are interested in languages as well as in software engineering to try Haskell and judge for themselves.
    - Peaker 10y ago
      There are a lot of tangible benefits over, say, OCaml. Let me use one particular representative one: STM. Haskell can successfully implement a performant STM with static guarantees regarding transactions. How would you add practical, guaranteed STM to OCaml? > are not reporting even 2x productivity gains An overall 2x productivity gain is huge. A 10% productivity gain is worth millions over the course of a year, for even a medium-sized software shop. There are other, very productive languages (at least for initially writing programs) but they tend to be far less reliable. There are other relatively reliable languages (e.g: Ada) but they are far less productive.
      - pron 10y ago
        > How would you add practical, guaranteed STM to OCaml? I don't see the relevance. Clojure has STM and isn't pure at all. I can't see why OCaml cannot do the same. > There are other, very productive languages (at least for initially writing programs) but they tend to be far less reliable. There are other relatively reliable languages (e.g: Ada) but they are far less productive. I understand that the Haskell community wishes this to be true -- and maybe it is -- but to date there's no data to support this. Whatever little data we have on bugs (the "GitHub study", which might not be dependable, but that's all we have) shows negligible-to-nonexistent advantage to Haskell over other languages.
        Peaker 10y ago
        > Clojure has STM and isn't pure at all. Not guaranteed STM. If you do IO in Clojure's STM, you just get a runtime error (assuming the IO does not forget to use the runtime-check that it isn't executing in STM context). > but there's absolutely no data to support this. Data of this sort is extremely expensive to collect reliably. I remember reading about a "GitHub study" that did not correctly classify what a "type error" is. Is that the one?
        pron 10y ago
        > Not guaranteed STM. If you do IO in Clojure's STM, you just get a runtime error Two things. 1/ "Guaranteeing" effects has little to do with PFP. 2/ There's no data to support that this level of guarantees has any effect on program quality. I'm all in favor of effect systems (though not PFP) because they're worth a try; but there's a long way to go from "interesting" and "it actually works!" especially if you have no data to support this. > Data of this sort is extremely expensive to collect reliably. Fine, but the alternative is to use an unproven, negligibly adopted (Haskell industry adoption rates are between 0.01-0.1%), badly tooled language, that requires a complete paradigm shift on faith and enthusiasm alone. I don't need, or want, to prove that Haskell isn't effective (TBH, I really wish Haskell, or any other novel approach did have some big gains); it is Haskell's proponents that need to support their claims with at least some convincing evidence. > Is that the one? I don't remember, but what does it matter? Again, I don't want to prove Haskell's ineffectiveness; it's people who want to convince others to use Haskell that should collect some evidence in its favor.
- tome 10y ago
  > You can have non-pure ... type-labeled effects. And what exactly would be the point of those?
  - pron 10y ago
    Why, restricting code, of course! A subroutine can be a continuation (as it is in non-PFP languages) and have the type-system restrict its actions rather than be modeled as a function (as it is in Haskell).
    - tome 10y ago
      I'm sorry, I really don't understand. My definition of pure language is "The language can encode a large class of non-side-effecting computations, and you can tell that they are non-side-effecting from their type". If you are in a non-pure language you cannot distinguish side-effecting from non-side-effecning computations just by looking at their type and thus, working with my definition, it seems impossible to have type-labelled effects in a non-pure language. What exactly is your definition?
      - pron 10y ago
        > What exactly is your definition? The problem is that there are two things here: purity, and functional. I don't know how to define purity alone, but let's say I take your definition, namely, the language defines a set of operations (that must include IO, and may or may not include mutation) and call them side-effects, and that the compiler enforces the transitive closure of said effects used by a subroutine. But Haskell employs a very specific design to achieve that, which is pure-functional, i.e., the subroutines in the language must be mathematical functions (or, in Haskell's case, partial functions), and mutation is declared to be a side-effect (which can be said to be a corollary of the first design choice). Neither is required by your definition of purity. A subroutine may be a continuation -- i.e. be able to block and resume -- and still be required to declare its side-effects, and mutation need not at all be considered a side-effect (see, e.g., how synchronous languages are still "referentially transparent" while allowing mutation).

by Peaker 10y ago

pron 10y ago

> It's the taking away of non-pure primitives and libraries -- and replacing those with type-labeled effects. PFP and typing are quite orthogonal. You can have effect systems in non-PFP, continuation-based languages (i.e. languages that don't equate computations with functions). You can have non-pure, non-monad-based type-labeled effects. > Haskell gains power in its framework for restricting code. Sure, but Haskell does this within a very specific design, based on extensional functional semantics. There are other ways of restricting what code can or cannot do that don't have the same semantics. Personally, I think that various effect systems may hold promise and are certainly interesting enough to try, but the PFP abstraction has so far failed to yield results commensurate with its cost.

Peaker 10y ago
> PFP and typing are quite orthogonal They are orthogonal in 1 technical sense. But the benefits are reaped from the combination. > the PFP abstraction has so far failed to yield results commensurate with its cost. You say this based on what? Me and other Haskell users believe that the costs are very minimal and the benefits are quite huge.
- pron 10y ago
  > But the benefits are reaped from the combination. Well, I happen to think that some forms of rich typing are quite beneficial, but that value-semantics is a negative. I don't see Haskell having any tangible benefits whatsoever over, say, OCaml (other than ecosystem-related stuff), which has one (relatively rich typing) but not the other (PFP). > You say this based on what? Based on the fact that the few Haskell shops out there -- despite them being composed of avid enthusiasts and people who devote a lot of thought into the Haskell way of thinking, are not reporting even 2x productivity gains (although I don't know what huge means to you). I mean, some say they feel those gains, but when you look at iteration speed, time to market etc., you see negligible advantage if at all. As to the cost, I won't argue with you, but I encourage people who are interested in languages as well as in software engineering to try Haskell and judge for themselves.
  - Peaker 10y ago
    There are a lot of tangible benefits over, say, OCaml. Let me use one particular representative one: STM. Haskell can successfully implement a performant STM with static guarantees regarding transactions. How would you add practical, guaranteed STM to OCaml? > are not reporting even 2x productivity gains An overall 2x productivity gain is huge. A 10% productivity gain is worth millions over the course of a year, for even a medium-sized software shop. There are other, very productive languages (at least for initially writing programs) but they tend to be far less reliable. There are other relatively reliable languages (e.g: Ada) but they are far less productive.
    - pron 10y ago
      > How would you add practical, guaranteed STM to OCaml? I don't see the relevance. Clojure has STM and isn't pure at all. I can't see why OCaml cannot do the same. > There are other, very productive languages (at least for initially writing programs) but they tend to be far less reliable. There are other relatively reliable languages (e.g: Ada) but they are far less productive. I understand that the Haskell community wishes this to be true -- and maybe it is -- but to date there's no data to support this. Whatever little data we have on bugs (the "GitHub study", which might not be dependable, but that's all we have) shows negligible-to-nonexistent advantage to Haskell over other languages.
      - Peaker 10y ago
        > Clojure has STM and isn't pure at all. Not guaranteed STM. If you do IO in Clojure's STM, you just get a runtime error (assuming the IO does not forget to use the runtime-check that it isn't executing in STM context). > but there's absolutely no data to support this. Data of this sort is extremely expensive to collect reliably. I remember reading about a "GitHub study" that did not correctly classify what a "type error" is. Is that the one?
        pron 10y ago
        > Not guaranteed STM. If you do IO in Clojure's STM, you just get a runtime error Two things. 1/ "Guaranteeing" effects has little to do with PFP. 2/ There's no data to support that this level of guarantees has any effect on program quality. I'm all in favor of effect systems (though not PFP) because they're worth a try; but there's a long way to go from "interesting" and "it actually works!" especially if you have no data to support this. > Data of this sort is extremely expensive to collect reliably. Fine, but the alternative is to use an unproven, negligibly adopted (Haskell industry adoption rates are between 0.01-0.1%), badly tooled language, that requires a complete paradigm shift on faith and enthusiasm alone. I don't need, or want, to prove that Haskell isn't effective (TBH, I really wish Haskell, or any other novel approach did have some big gains); it is Haskell's proponents that need to support their claims with at least some convincing evidence. > Is that the one? I don't remember, but what does it matter? Again, I don't want to prove Haskell's ineffectiveness; it's people who want to convince others to use Haskell that should collect some evidence in its favor.
tome 10y ago
> You can have non-pure ... type-labeled effects. And what exactly would be the point of those?
- pron 10y ago
  Why, restricting code, of course! A subroutine can be a continuation (as it is in non-PFP languages) and have the type-system restrict its actions rather than be modeled as a function (as it is in Haskell).
  - tome 10y ago
    I'm sorry, I really don't understand. My definition of pure language is "The language can encode a large class of non-side-effecting computations, and you can tell that they are non-side-effecting from their type". If you are in a non-pure language you cannot distinguish side-effecting from non-side-effecning computations just by looking at their type and thus, working with my definition, it seems impossible to have type-labelled effects in a non-pure language. What exactly is your definition?
    - pron 10y ago
      > What exactly is your definition? The problem is that there are two things here: purity, and functional. I don't know how to define purity alone, but let's say I take your definition, namely, the language defines a set of operations (that must include IO, and may or may not include mutation) and call them side-effects, and that the compiler enforces the transitive closure of said effects used by a subroutine. But Haskell employs a very specific design to achieve that, which is pure-functional, i.e., the subroutines in the language must be mathematical functions (or, in Haskell's case, partial functions), and mutation is declared to be a side-effect (which can be said to be a corollary of the first design choice). Neither is required by your definition of purity. A subroutine may be a continuation -- i.e. be able to block and resume -- and still be required to declare its side-effects, and mutation need not at all be considered a side-effect (see, e.g., how synchronous languages are still "referentially transparent" while allowing mutation).