9 ms·

I cannot say that getting upset over people using jokey memes to communicate ideas (Haskell is more likely to be correct after a successful type-check than othe

I cannot say that getting upset over people using jokey memes to communicate ideas (Haskell is more likely to be correct after a successful type-check than other langs) is likely to do you much good. I like Epictetus for when I notice I am upset about something that isn't within my control: http://classics.mit.edu/Epictetus/epicench.html http://classics.mit.edu/Epictetus/epicench.html

infraruby 12y ago
> Haskell is more likely to be correct after a successful type-check than other langs Is there any empirical evidence for this?
- coolsunglasses 12y ago
  You really don't want to lean on empiricism for PL, but: http://www.cs.yale.edu/publications/techreports/tr1049.pdf http://www.cs.yale.edu/publications/techreports/tr1049.pdf
  - infraruby 12y ago
    > You really don't want to lean on empiricism for PL Why not? considering "more likely to be correct" is an empirical claim. > http://www.cs.yale.edu/publications/techreports/tr1049.pdf http://www.cs.yale.edu/publications/techreports/tr1049.pdf Haskell vs Ada, C++, etc. in 1994.
    - coolsunglasses 12y ago
      Because all comparative PL studies are nonsense, including that one. Look at the experiment methodology described in most of them. We have something better for evaluating PLs.
      - infraruby 12y ago
        > We have something better for evaluating PLs. Do tell! How do you evaluate empirical claims (about programming languages) without empirical evidence?
      - seanmcdirmid 12y ago
        Empirical evaluations break down quickly as the complexity of what is being measured increases, so your best bet in doing a study is to focus on one or a few features. PLs are of course evaluated over time in the market place over time, like any other designed artifact.
    - the_af 12y ago
      I love that report and find it very inspiring (and it gives me an intuition that Haskell has an edge over the other languages), but the methodology is very disappointing: - The requirements were mostly up to the interpretation of implementors, which more or less decided the scope of their programs. - All results were self-reported. Even ruling out dishonesty, there are a lot of ways uncontrolled experimenters can report incorrect results. - Many implementations weren't even runnable. - No code was run by the reviewers, at all. I really would love to see a more serious attempt at this experiment (probably with more modern languages).
- mightybyte 12y ago
  In this I prefer logical reasoning to empirical evidence. Consider a function that takes a list of things and returns the last one. Let's write that function in Haskell. last :: [a] -> a Without looking at an implementation, let's think of how many ways this function could possibly go wrong? It could return the first element of the list instead of the last one. It could return the second to last element of the list. More generally, it could return any one of the elements of the list that was passed in. But that's it (other than the empty list case which for simplicity we can ignore because it's a condition we can statically detect). There are no other possibilities, period. Now think about implementing this function in any other language. What about Java? public Object last(Object objs[]) This function can return any of the elements of the incoming array. It could also return null. It could also return the int 42, or the string "hello". It could delete files on your hard drive, open a network connection and phone home to the NSA. I could go on and on. The point here is that you simply can't say as much about what this function could be doing as we could say about the Haskell version. This is the case for every mainstream language in wide use today. Some languages allow you to say a little more than others, but none of them come close to what Haskell gives you. Because of this, I don't really feel a pressing need for empirical evidence. Logical reasoning lets me make that claim quite confidently.
  - infraruby 12y ago
    > There are no other possibilities, period. That's true! You have proved the original (deductive) claim "if it compiles, it works" for that one specific example, but that does not hold in general. In general you may prefer the alternative (inductive) claim "more likely to be correct", but that claim requires empirical evidence.
    - mightybyte 12y ago
      The inductive claim "more likely to be correct" is strongly supported by the evidence gained from enumerating the number of ways the functions could go wrong. Now if we want to expand our domain out from just that function to programs in general, we need an idea of how applicable those ideas are to larger programs. The biggest source of reducing error cases in my example was purity. Some parts of programs (namely the side effecting parts) can't be expressed as pure functions. So the next piece of evidence we need is an estimate of the percentage of large programs that can be expressed as pure functions. From my experience writing Haskell full-time for the last five years I can tell you that it is very substantial. Even in very impure code you can often factor out lots of small pure operations. I feel very safe in claiming that at least a third of Haskell code can be written with pure functions, and I think it's likely greater than half. (It could be a lot higher, but I'm trying to keep the confidence level fairly high.) You don't have to take my word for this. You can go off and browse through millions of lines of Haskell on [Hackage](http://hackage.haskell.org/packages/ http://hackage.haskell.org/packages/) and see for yourself. It probably wouldn't be too difficult to write an automated script to do this. Now we've seen that pure functions have a small fraction of the error conditions that impure functions have. And we've seen that maybe half of all the code we write can be expressed that way. That's a pretty dramatic reduction in the number of potential error conditions we might encounter for even complex programs. That is why I think the claim "more likely to be correct" is strongly supported by evidence.
- eli_gottlieb 12y ago
  Oh, hey, I get to copypasta one of the citations from my Master's thesis. Yes, there is empirical evidence! http://macbeth.cs.ucdavis.edu/lang_study.pdf http://macbeth.cs.ucdavis.edu/lang_study.pdf >Abstract: >What is the effect of programming languages on software quality? This question has been a topic of much debate for a very long time. In this study, we gather a very large data set from GitHub (729 projects, 80 Million SLOC, 29,000 authors, 1.5 million commits, in 17 languages) in an attempt to shed some empirical light on this question. This reasonably large sample size allows us to use a mixed-methods approach, combining multiple regression modeling with visualization and text analytics, to study the effect of language features such as static v.s. dynamic typing, strong v.s. weak typing on software quality. By triangulating findings from different methods, and controlling for confounding effects such as team size, project size, and project history, we report that language design does have a significant, but modest effect on software quality. Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat better than dynamic typing. We also find that functional languages are somewhat better than procedural languages. It is worth noting that these modest effects arising from language design are overwhelmingly dominated by the process factors such as project size, team size, and commit size. However, we hasten to caution the reader that even these modest effects might quite possibly be due to other, intangible process factors, e.g., the preference of certain personality types for functional, static and strongly typed languages.
AnimalMuppet 12y ago
So let's see here: You asked why I was picking the interpretation I did. I answered. You respond about me getting upset, and commend Epictetus. Where, exactly, did I say that I was getting upset? I was stating why I interpreted those guys as being serious rather than joking in their claims. What does Epictetus have to say to whether they were tongue-in-cheek or not? Are you just arguing to argue? Because you're sure not responding to what I said. > Haskell is more likely to be correct after a successful type-check than (most) other langs True.
sigmaml 12y ago
> "I cannot say that getting upset over people using jokey memes to communicate ideas (Haskell is more likely to be correct after a successful type-check than other langs) is likely to do you much good." You have, evidently, taken the least-charitable interpretation of GP's post yourself. And, right in the context of a discussion where you were the person to introduce that phrase!

infraruby 12y ago

> Haskell is more likely to be correct after a successful type-check than other langs Is there any empirical evidence for this?

coolsunglasses 12y ago
You really don't want to lean on empiricism for PL, but: http://www.cs.yale.edu/publications/techreports/tr1049.pdf http://www.cs.yale.edu/publications/techreports/tr1049.pdf
- infraruby 12y ago
  > You really don't want to lean on empiricism for PL Why not? considering "more likely to be correct" is an empirical claim. > http://www.cs.yale.edu/publications/techreports/tr1049.pdf http://www.cs.yale.edu/publications/techreports/tr1049.pdf Haskell vs Ada, C++, etc. in 1994.
  - coolsunglasses 12y ago
    Because all comparative PL studies are nonsense, including that one. Look at the experiment methodology described in most of them. We have something better for evaluating PLs.
    - infraruby 12y ago
      > We have something better for evaluating PLs. Do tell! How do you evaluate empirical claims (about programming languages) without empirical evidence?
    - seanmcdirmid 12y ago
      Empirical evaluations break down quickly as the complexity of what is being measured increases, so your best bet in doing a study is to focus on one or a few features. PLs are of course evaluated over time in the market place over time, like any other designed artifact.
  - the_af 12y ago
    I love that report and find it very inspiring (and it gives me an intuition that Haskell has an edge over the other languages), but the methodology is very disappointing: - The requirements were mostly up to the interpretation of implementors, which more or less decided the scope of their programs. - All results were self-reported. Even ruling out dishonesty, there are a lot of ways uncontrolled experimenters can report incorrect results. - Many implementations weren't even runnable. - No code was run by the reviewers, at all. I really would love to see a more serious attempt at this experiment (probably with more modern languages).
mightybyte 12y ago
In this I prefer logical reasoning to empirical evidence. Consider a function that takes a list of things and returns the last one. Let's write that function in Haskell. last :: [a] -> a Without looking at an implementation, let's think of how many ways this function could possibly go wrong? It could return the first element of the list instead of the last one. It could return the second to last element of the list. More generally, it could return any one of the elements of the list that was passed in. But that's it (other than the empty list case which for simplicity we can ignore because it's a condition we can statically detect). There are no other possibilities, period. Now think about implementing this function in any other language. What about Java? public Object last(Object objs[]) This function can return any of the elements of the incoming array. It could also return null. It could also return the int 42, or the string "hello". It could delete files on your hard drive, open a network connection and phone home to the NSA. I could go on and on. The point here is that you simply can't say as much about what this function could be doing as we could say about the Haskell version. This is the case for every mainstream language in wide use today. Some languages allow you to say a little more than others, but none of them come close to what Haskell gives you. Because of this, I don't really feel a pressing need for empirical evidence. Logical reasoning lets me make that claim quite confidently.
- infraruby 12y ago
  > There are no other possibilities, period. That's true! You have proved the original (deductive) claim "if it compiles, it works" for that one specific example, but that does not hold in general. In general you may prefer the alternative (inductive) claim "more likely to be correct", but that claim requires empirical evidence.
  - mightybyte 12y ago
    The inductive claim "more likely to be correct" is strongly supported by the evidence gained from enumerating the number of ways the functions could go wrong. Now if we want to expand our domain out from just that function to programs in general, we need an idea of how applicable those ideas are to larger programs. The biggest source of reducing error cases in my example was purity. Some parts of programs (namely the side effecting parts) can't be expressed as pure functions. So the next piece of evidence we need is an estimate of the percentage of large programs that can be expressed as pure functions. From my experience writing Haskell full-time for the last five years I can tell you that it is very substantial. Even in very impure code you can often factor out lots of small pure operations. I feel very safe in claiming that at least a third of Haskell code can be written with pure functions, and I think it's likely greater than half. (It could be a lot higher, but I'm trying to keep the confidence level fairly high.) You don't have to take my word for this. You can go off and browse through millions of lines of Haskell on [Hackage](http://hackage.haskell.org/packages/ http://hackage.haskell.org/packages/) and see for yourself. It probably wouldn't be too difficult to write an automated script to do this. Now we've seen that pure functions have a small fraction of the error conditions that impure functions have. And we've seen that maybe half of all the code we write can be expressed that way. That's a pretty dramatic reduction in the number of potential error conditions we might encounter for even complex programs. That is why I think the claim "more likely to be correct" is strongly supported by evidence.
eli_gottlieb 12y ago
Oh, hey, I get to copypasta one of the citations from my Master's thesis. Yes, there is empirical evidence! http://macbeth.cs.ucdavis.edu/lang_study.pdf http://macbeth.cs.ucdavis.edu/lang_study.pdf >Abstract: >What is the effect of programming languages on software quality? This question has been a topic of much debate for a very long time. In this study, we gather a very large data set from GitHub (729 projects, 80 Million SLOC, 29,000 authors, 1.5 million commits, in 17 languages) in an attempt to shed some empirical light on this question. This reasonably large sample size allows us to use a mixed-methods approach, combining multiple regression modeling with visualization and text analytics, to study the effect of language features such as static v.s. dynamic typing, strong v.s. weak typing on software quality. By triangulating findings from different methods, and controlling for confounding effects such as team size, project size, and project history, we report that language design does have a significant, but modest effect on software quality. Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat better than dynamic typing. We also find that functional languages are somewhat better than procedural languages. It is worth noting that these modest effects arising from language design are overwhelmingly dominated by the process factors such as project size, team size, and commit size. However, we hasten to caution the reader that even these modest effects might quite possibly be due to other, intangible process factors, e.g., the preference of certain personality types for functional, static and strongly typed languages.

AnimalMuppet 12y ago

So let's see here: You asked why I was picking the interpretation I did. I answered. You respond about me getting upset, and commend Epictetus. Where, exactly, did I say that I was getting upset? I was stating why I interpreted those guys as being serious rather than joking in their claims. What does Epictetus have to say to whether they were tongue-in-cheek or not? Are you just arguing to argue? Because you're sure not responding to what I said. > Haskell is more likely to be correct after a successful type-check than (most) other langs True.

sigmaml 12y ago

> "I cannot say that getting upset over people using jokey memes to communicate ideas (Haskell is more likely to be correct after a successful type-check than other langs) is likely to do you much good." You have, evidently, taken the least-charitable interpretation of GP's post yourself. And, right in the context of a discussion where you were the person to introduce that phrase!