2 ms·

>> Haskell was and still is motivated by enabling software development gains > The same can be said about nearly every language. This clearly isn't true. For

• pron 10y ago
  Nobody knows if Haskell's design is great for software development, and if it is, by how much and whether it justifies the costs. That's precisely why we need data. > Haskell just happens to have come from academia and is still heavily used in academia. Haskell isn't heavily used in academia at all. My guess is that most CS professors -- like most developers -- have hardly even heard of it, let alone used it. It is heavily used among researchers who's job it is to study the design of languages like Haskell. Languages that are heavily used in academia are C, Python, Java and maybe a few more. > There are many experience reports published all the time at conferences and in academic journals, Where? I've looked. If you want to see what a good report looks like, take a look at this one[1]. It's got some background, and then lot's of analysis of pros and cons, with plenty of numbers. I found it so convincing that I tried the language it advocated, and ended up adopting it. I'd seen similar (even more comprehensive) reports for Java back in the early '00s before deciding our team should adopt it. I haven't seen anything similar for Haskell. And again -- the more costly the adoption, the more information required before trying. > going back decades. None however will give you the quantitative metrics you seem to be asking for, because it is almost impossible to do such a comparison. I don't want a comparison, and what I'm asking for has been done at some point for nearly every language that has gained widespread adoption. I just want to know how much time and effort has gone into a single project, a breakdown of costs, and a subjective analysis of pros and cons. You see such reports being written from time to time about other languages (although usually with far more adoption than Haskell). [1]: Slides: http://tla2012.loria.fr/contributed/newcombe-slides.pdf http://tla2012.loria.fr/contributed/newcombe-slides.pdf Report 1: http://glat.info/pdf/formal-methods-amazon-2014-11.pdf http://glat.info/pdf/formal-methods-amazon-2014-11.pdf Report 2: http://link.springer.com/chapter/10.1007/978-3-662-43652-3_3 http://link.springer.com/chapter/10.1007/978-3-662-43652-3_3
  • willtim 10y ago
    > Nobody knows if Haskell's design is great for software development We can certainly say that uncontrolled side-effects, manual memory-management and dynamic types is bad for software development in the large. I'll stop here because I don't which to argue the semantics of what does are does not constitute significant use or significant research.
    • pron 10y ago
      > We can certainly say that uncontrolled side-effects We most certainly cannot say that. There's no indication or even a hint that uncontrolled side-effects are a cause of expensive bugs. As a Haskell developer, however, I assume that you consider mutation to be a side-effect (because in pure-FP mutation is a side effect), and it is true that uncontrolled, non-transactional global-state mutation is not such a great idea, but most developers know not to do that in any language, and if you want language-level enforcement on mutation, you can get that for a fraction of the price of Haskell. There's also nothing to suggest that Haskell's approach is a good one (as opposed to, say, Clojure's or Erlang's) or even that Haskell's cure isn't worse than the disease. > manual memory-management Absolutely, and you can get automatic memory management for a fraction of the cost. > and dynamic types You get static types for a fraction of the cost, too. > argue the semantics of what does are does not constitute significant use It's fine for a language to not have wide adoption. That doesn't mean it's not good or even not great. It's also fine -- and I do that, too -- for people to say, I really like that language, I find it elegant, and I feel it helps me develop. What isn't fine is endless hype with claims of significant bottom line benefit but little effort to collect even anecdotal evidence (and I don't mean evidence that Haskell programs can run, or that you really like the language; I mean evidence of the extent of the claimed benefit).
      • willtim 10y ago
        > There's no indication or even a hint that uncontrolled side-effects are a cause of expensive bugs. Uncontrolled side-effects destroy the ability to reason about software and when one can no longer reason effectively, bugs will happen. This is obvious to anyone who has worked on large systems. Whether it matters or not, depends on the domain. In finance, it is absolutely critical that we can reproduce a calculation and that for example, the current date is not read from the system deep inside the code somewhere. Having the compiler guarantee this for us is a huge win. > Absolutely, and you can get automatic memory management for a fraction of the cost. > You get static types for a fraction of the cost, too. What do you actually know about the cost of Haskell adoption? If you want to accuse me of making unsubstantiated claims, your position would be more tenable without making them yourself!