6 ms·

> 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

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

by Peaker 10y ago

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.