5 ms·

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 w

by 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
      Peaker started off by explaining that > Haskell gains power in its framework for restricting code and you have nudged the thread in the direction of your pet topic > it's people who want to convince others to use Haskell that should collect some evidence in its favor How exactly did we end up here?
      - pron 10y ago
        I started off by explaining why Haskell needs monads and why they don't add power, and later why PFP and restricting what code can do are orthogonal. Peaker then spoke of tangible gains, and I said that something is not tangible if you can't show it, and then you nudged the thread in the direction of your pet project which, apparently, is patronizing people. More to the point, if you claim Haskell (or, in particular, monads) has theoretical benefits, you need to be able to explain them (and restricting effect is not a theoretical explanation as it doesn't require monads); if your explanation is "this has benefits in practice" then you're really claiming empirical, rather than theoretical, benefits, but then you need to be able to support those. If you go around saying monads have theoretical benefits but when debated claim empirical benefits and then don't support those, expect to be called out for selling snake-oil (and just to be clear, my point can be summarized as follows: Haskell takes a very clear, very opinionated theoretical approach[1], which is beautifully elegant but is not theoretically better or worse, just very different, with its particular pros and cons. Empirically, I claim, Haskell has not yet shown significant benefits). [1]: Subroutines as functions; mutation as effect; HM types (+ typeclasses). Type system aside, there are obviously many alternatives (other than "classical" empirical languages). For example, languages that require full verification for safety-critical realtime code often employ the synchronous model. In that model, each subroutine isn't a function (but a continuation), but the program itself can be viewed as a function from one program state to the next, and mutation isn't a side-effect, but is very much controlled (see https://who.rocq.inria.fr/Dumitru.Potop_Butucaru/potopEmbeddedHandbook.pdf https://who.rocq.inria.fr/Dumitru.Potop_Butucaru/potopEmbedd...). This is a model that lends itself very nicely to formal reasoning, and there are others.

by Peaker 10y ago

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
    Peaker started off by explaining that > Haskell gains power in its framework for restricting code and you have nudged the thread in the direction of your pet topic > it's people who want to convince others to use Haskell that should collect some evidence in its favor How exactly did we end up here?
    - pron 10y ago
      I started off by explaining why Haskell needs monads and why they don't add power, and later why PFP and restricting what code can do are orthogonal. Peaker then spoke of tangible gains, and I said that something is not tangible if you can't show it, and then you nudged the thread in the direction of your pet project which, apparently, is patronizing people. More to the point, if you claim Haskell (or, in particular, monads) has theoretical benefits, you need to be able to explain them (and restricting effect is not a theoretical explanation as it doesn't require monads); if your explanation is "this has benefits in practice" then you're really claiming empirical, rather than theoretical, benefits, but then you need to be able to support those. If you go around saying monads have theoretical benefits but when debated claim empirical benefits and then don't support those, expect to be called out for selling snake-oil (and just to be clear, my point can be summarized as follows: Haskell takes a very clear, very opinionated theoretical approach[1], which is beautifully elegant but is not theoretically better or worse, just very different, with its particular pros and cons. Empirically, I claim, Haskell has not yet shown significant benefits). [1]: Subroutines as functions; mutation as effect; HM types (+ typeclasses). Type system aside, there are obviously many alternatives (other than "classical" empirical languages). For example, languages that require full verification for safety-critical realtime code often employ the synchronous model. In that model, each subroutine isn't a function (but a continuation), but the program itself can be viewed as a function from one program state to the next, and mutation isn't a side-effect, but is very much controlled (see https://who.rocq.inria.fr/Dumitru.Potop_Butucaru/potopEmbeddedHandbook.pdf https://who.rocq.inria.fr/Dumitru.Potop_Butucaru/potopEmbedd...). This is a model that lends itself very nicely to formal reasoning, and there are others.