4 ms·

> 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

• pron 11y ago
  > It would be simply impossible for the stated benefits not to be beneficial in practice. The only question is whether the benefits are outweighed by the drawbacks. If you have already paid the one-off cost of learning the gnarly corners of Haskell then those drawbacks are significantly diminished. Provided that you think that the only significant drawback is the learning curve. I think that the PFP abstraction itself is a drawback, and that you can get most of Haskell's benefits (leaving aside their real-world value for a moment) without it. In particular, I think that you cannot point at any real-world benefits of the Haskell approach over, say, the OCaml approach, and that's even before applying things like effect systems to OCaml. > people make decisions on programming languages all the time without such research Of course, but if they do, they cannot claim real benefits that aren't real. The reason some people use Haskell is that it fits well with how they like to think about and write code; the reason many people don't use Haskell is because it doesn't fit with their preferred style, and because there is no compelling evidence for why they should even try to change their methodology. My only "insistence" is that you either claim actual benefits and present empirical data to support it, or don't present empirical data but claim only personal preference. What you don't get to do is say, "Haskell leads to code with significantly fewer serious bugs" while at the same time not show any evidence that it does. The reason you don't get to do that is that such a claim is one with serious (theoretical and financial) implications, and strong claims require strong evidence (or at least some more convincing evidence than what we have). > Furthermore, I wouldn't trust any empirical research on languages any more than I would trust empirical research on cholesterol OK, but you're saying that I should go full vegan based on even less than that. > It's not ideal, but it's also not wrong. How do you know it's not wrong? But let me refine this. I agree that it's very likely that "Haskell is more reliable than Python and more productive than Ada", but that's not the real argument. The real argument is that Haskell is a lot more reliable than Python and a lot more productive than Ada. I don't see how you can possibly claim that based just on personal experience. But let me refine this further: there's personal experience and personal experience. There's personal experience based on measuring actual project costs and comparing them -- even though projects are not exactly comparable -- now that's not ideal but not wrong, and there's personal experience based on gut feeling. I don't know how you can say that that's not wrong. Also, there's collected personal experience from hundreds of projects in many domains and various sizes -- that's not ideal but not wrong -- and there's personal experience from a handful of projects, nearly all quite small, in one or two domains. I don't know how you can say that's not wrong (unless you qualify the domain, which you don't). At this point in time, all we can say about Haskell is this: some people greatly enjoy Haskell's programming paradigm; some people report possibly significant but not big gains in the handful of medium-to-large production projects where the language has been used. So far the approach is showing some (though not great) promise and requires further consideration.
  • tome 11y ago
    > Provided that you think that the only significant drawback is the learning curve. No, you misread me. I acknowledge other significant drawbacks, such as immaturity of tooling and infrastructure. > I think that the PFP abstraction itself is a drawback, and that you can get most of Haskell's benefits (leaving aside their real-world value for a moment) without it. OK, that would be great! I am genuinely interested in understanding how to do that. I would love to see PFP as a drawback and obtain its benefits without requiring its rigors. So far I have failed to understand your ideas about how to do that and I can only continue to see PFP as a massive boon. > In particular, I think that you cannot point at any real-world benefits of the Haskell approach over, say, the OCaml approach, and that's even before applying things like effect systems to OCaml. (One of) the real-world benefit(s) is that I can write a substantial part of a program and know from inspecting only a single line (its type signature) what effects it performs. How can OCaml give me that benefit? > What you don't get to do is say, "Haskell leads to code with significantly fewer serious bugs" while at the same time not show any evidence that it does. The reason you don't get to do that is that such a claim is one with serious (theoretical and financial) implications, and strong claims require strong evidence (or at least some more convincing evidence than what we have). I think that says more about how you interpret informal comments on the internet than it does about those making the comments. > > Furthermore, I wouldn't trust any empirical research on languages any more than I would trust empirical research on cholesterol > OK, but you're saying that I should go full vegan based on even less than that. Interesting. Where did I say you should go (the equivalent of) "full vegan"? > > It's not ideal, but it's also not wrong. > How do you know it's not wrong? At least, it is not known to be wrong. > But let me refine this. [... snipped useful elucidation ...] > At this point in time, all we can say about Haskell is this: some people greatly enjoy Haskell's programming paradigm; some people report possibly significant but not big gains in the handful of medium-to-large production projects where the language has been used. So far the approach is showing some (though not great) promise and requires further consideration. Entirely agreed. I think my gripe with you at this point is that you read too much in to people's informal claims and cause unnecessary aggravation by derailing threads. It's quite clear that you could actually contribute constructively, so I wish you would. Please can you explain in detail how I can get the benefits of PFP without its drawbacks?