4 ms·

> Nobody knows if Haskell's design is great for software development We can certainly say that uncontrolled side-effects, manual memory-management and dynamic

by 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!
  - pron 10y ago
    > 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. I have worked on systems comprising 10MLOCs over a career of ~20 years, both as a developer and as a manager, and this isn't obvious to me at all. But I separate mutation from side-effects, because mutation is better defined, and what side-effects mean varies by language. Global mutation is important to control, but there are lots of ways to do that. Other side-effects (and especially IO)? Not so much. > Having the compiler guarantee this for us is a huge win. It is almost as trivial to guarantee that in Java, although maybe not during compilation. > 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! Oh, while I haven't written much more than Hello, World programs in Haskell (but I have programmed in SML a bit years ago, and a fair bit in Scheme and Clojure), I am no stranger to the theory of pure-FP (simply typed LC w/ polymorphism, functional semantics, monadic composition etc; I'm less familiar with call-by-value semantics, though). It is pretty radically different from most other styles of programming, including imperative-functional, both in terms of coding as well as tools such as debuggers and profilers.
    - willtim 10y ago
      I also have ~20 years experience developing software. I have worked on 10+ MLOC Java and C++ systems at UBS, Deutsche Bank, Morgan Stanley, Lehman Brothers and others. I came to Haskell precisely because of my experience working on such large scale systems with mainstream languages. I have spent the last 4 years as a professional Haskell developer, first at Barclays, now at SCB. While I could probably stomach giving up purity in a small project, you'd only be able to take away sum types and pattern matching from my cold dead hands.
      - pron 10y ago
        Personally, I am a bit skeptical of language-level features in general (as opposed to runtime features) to provide significant benefit compared to their high cost[1], and doubly so in general purpose languages, but that is precisely why I am interested in good technical reports about the pros and cons of languages, and those are sorely missing. At this point, whatever public information we do have seems to suggest that no company is significantly better than most others when it comes to delivering complex large software. There are a few exceptions where specific attributes are concerned. For example, Altran UK (Praxis) do seem to be rather exceptional in their ability to provide large verified software (they use Z for specification and Ada SPARK for coding), and they do have technical reports that are not completely devoid of useful information. [1]: This isn't even about a particular language (although different languages do have different cost of adoption). Any language that doesn't have excellent interop with existing libraries and legacy code has a very high cost of adoption (and yeah, we've tried Scala years ago, and the experience was far from good).

by willtim 10y ago

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!
- pron 10y ago
  > 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. I have worked on systems comprising 10MLOCs over a career of ~20 years, both as a developer and as a manager, and this isn't obvious to me at all. But I separate mutation from side-effects, because mutation is better defined, and what side-effects mean varies by language. Global mutation is important to control, but there are lots of ways to do that. Other side-effects (and especially IO)? Not so much. > Having the compiler guarantee this for us is a huge win. It is almost as trivial to guarantee that in Java, although maybe not during compilation. > 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! Oh, while I haven't written much more than Hello, World programs in Haskell (but I have programmed in SML a bit years ago, and a fair bit in Scheme and Clojure), I am no stranger to the theory of pure-FP (simply typed LC w/ polymorphism, functional semantics, monadic composition etc; I'm less familiar with call-by-value semantics, though). It is pretty radically different from most other styles of programming, including imperative-functional, both in terms of coding as well as tools such as debuggers and profilers.
  - willtim 10y ago
    I also have ~20 years experience developing software. I have worked on 10+ MLOC Java and C++ systems at UBS, Deutsche Bank, Morgan Stanley, Lehman Brothers and others. I came to Haskell precisely because of my experience working on such large scale systems with mainstream languages. I have spent the last 4 years as a professional Haskell developer, first at Barclays, now at SCB. While I could probably stomach giving up purity in a small project, you'd only be able to take away sum types and pattern matching from my cold dead hands.
    - pron 10y ago
      Personally, I am a bit skeptical of language-level features in general (as opposed to runtime features) to provide significant benefit compared to their high cost[1], and doubly so in general purpose languages, but that is precisely why I am interested in good technical reports about the pros and cons of languages, and those are sorely missing. At this point, whatever public information we do have seems to suggest that no company is significantly better than most others when it comes to delivering complex large software. There are a few exceptions where specific attributes are concerned. For example, Altran UK (Praxis) do seem to be rather exceptional in their ability to provide large verified software (they use Z for specification and Ada SPARK for coding), and they do have technical reports that are not completely devoid of useful information. [1]: This isn't even about a particular language (although different languages do have different cost of adoption). Any language that doesn't have excellent interop with existing libraries and legacy code has a very high cost of adoption (and yeah, we've tried Scala years ago, and the experience was far from good).