6 ms·

For completeness, would you mind posting a link to some of this evidence so we don't have to take your word for it?

username90 5y ago
Sorting is an example, quicksort is fast since it is done in place and mutates the data instead of allocating new memory. Very few algorithms are not faster with mutable variables.
- benrbray 5y ago
  As I understand it, immutability usually refers to mutable data structures hidden behind an interface that allows the programmer to reason about things as if they were immutable. The naive implementation is of course to duplicate all data whenever a change is made, but pure / immutable languages use smarter things like persistent data structures behind the scenes. If the compiler knows the original data is never needed, it can optimize away the old copies, too. At least that's the hope, I'm not sure how true it is.
  - username90 5y ago
    > As I understand it, immutability usually refers to mutable data structures hidden behind an interface that allows the programmer to reason about things as if they were immutable. That is the definition of an algorithm, not immutability.
tsimionescu 5y ago
First of all, I am arguing for the base case: absent any studies, the null hypothesis is naturally that there are no major differences between programming paradigms. On the issue of bug counts, there was one huge study, that was successfully reproduced [0], which finds that there is a real but small negative correlation between FP and bug counts in large GitHub projects. For productivity I haven't been able to find any large-scale studies that compare functional vs imperative/OOP languages. I did find one small scale study [1] that found significantly better productivity for Haskell (and a Lisp dialect) vs Ada, C++ and a few others, but it was about a specific small prototype problem with just a handful of programmers participating (the Haskell program had 85 lines, the worse, C++, had 1105; and programs took between 10h and 54h to finish - hardly representative of large-scale coding). Most other studies on productivity that I could find [2], [3] didn't include any FP languages at all. [0] https://arxiv.org/pdf/1901.10220.pdf https://arxiv.org/pdf/1901.10220.pdf [1] https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.368.1058&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36... [2] https://www.e-informatyka.pl/attach/e-Informatica_-_Volume_12/eInformatica2018Art2.pdf https://www.e-informatyka.pl/attach/e-Informatica_-_Volume_1... [3] https://www.researchgate.net/publication/4261726_Do_Programming_Languages_Affect_Productivity_A_Case_Study_Using_Data_from_Open_Source_Projects https://www.researchgate.net/publication/4261726_Do_Programm...
- mightybyte 5y ago
  > There is also a pretty big body of evidence already that doesn't show any hugely significant (say, 2x) changes in productivity > For productivity I haven't been able to find any large-scale studies that compare functional vs imperative/OOP languages I'm having trouble reconciling these two statements of yours.
nonameiguess 5y ago
You can look at the R data.table package. R by default is a purely functional language, and the built-in data.frame type for in-memory tabular data is immutable. That means computing anything that changes the data requires copying it all. The data.table packages achieved pretty impressive speed-ups by dropping down into C and doing everything in-place. Also makes it harder to run out of memory. Granted, some effects like this can be mitigated with sufficiently clever language design. Haskell with lazy evaluation. I believe some compilers for functional languages will reuse memory addresses they can prove nothing else refers to, so in reality they are mutating in-place even if semantically the variables are "immutable." Heck, even Python does that with the built-in immutable types. When you assign the changed data to a new name, it doesn't actually allocate new memory and just does it in-place under the hood. In cases like that, the data isn't really "immutable." It just can't be mutated by the programmer, only by the runtime or compiler. Of course, if we want to get sufficiently pedantic, no data is ever immutable. The law may say a ledger is append-only, but nothing is stopping an accountant from just lying. A compiler may prevent you from assigning new data to an already-existing name binding, but a compiler can't stop someone from using rowhammer or an x-ray machine or something and flipping the bits in memory anyway.

Sorting is an example, quicksort is fast since it is done in place and mutates the data instead of allocating new memory. Very few algorithms are not faster with mutable variables.

benrbray 5y ago
As I understand it, immutability usually refers to mutable data structures hidden behind an interface that allows the programmer to reason about things as if they were immutable. The naive implementation is of course to duplicate all data whenever a change is made, but pure / immutable languages use smarter things like persistent data structures behind the scenes. If the compiler knows the original data is never needed, it can optimize away the old copies, too. At least that's the hope, I'm not sure how true it is.
- username90 5y ago
  > As I understand it, immutability usually refers to mutable data structures hidden behind an interface that allows the programmer to reason about things as if they were immutable. That is the definition of an algorithm, not immutability.

tsimionescu 5y ago

First of all, I am arguing for the base case: absent any studies, the null hypothesis is naturally that there are no major differences between programming paradigms. On the issue of bug counts, there was one huge study, that was successfully reproduced [0], which finds that there is a real but small negative correlation between FP and bug counts in large GitHub projects. For productivity I haven't been able to find any large-scale studies that compare functional vs imperative/OOP languages. I did find one small scale study [1] that found significantly better productivity for Haskell (and a Lisp dialect) vs Ada, C++ and a few others, but it was about a specific small prototype problem with just a handful of programmers participating (the Haskell program had 85 lines, the worse, C++, had 1105; and programs took between 10h and 54h to finish - hardly representative of large-scale coding). Most other studies on productivity that I could find [2], [3] didn't include any FP languages at all. [0] https://arxiv.org/pdf/1901.10220.pdf https://arxiv.org/pdf/1901.10220.pdf [1] https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.368.1058&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36... [2] https://www.e-informatyka.pl/attach/e-Informatica_-_Volume_12/eInformatica2018Art2.pdf https://www.e-informatyka.pl/attach/e-Informatica_-_Volume_1... [3] https://www.researchgate.net/publication/4261726_Do_Programming_Languages_Affect_Productivity_A_Case_Study_Using_Data_from_Open_Source_Projects https://www.researchgate.net/publication/4261726_Do_Programm...

mightybyte 5y ago
> There is also a pretty big body of evidence already that doesn't show any hugely significant (say, 2x) changes in productivity > For productivity I haven't been able to find any large-scale studies that compare functional vs imperative/OOP languages I'm having trouble reconciling these two statements of yours.

nonameiguess 5y ago

You can look at the R data.table package. R by default is a purely functional language, and the built-in data.frame type for in-memory tabular data is immutable. That means computing anything that changes the data requires copying it all. The data.table packages achieved pretty impressive speed-ups by dropping down into C and doing everything in-place. Also makes it harder to run out of memory. Granted, some effects like this can be mitigated with sufficiently clever language design. Haskell with lazy evaluation. I believe some compilers for functional languages will reuse memory addresses they can prove nothing else refers to, so in reality they are mutating in-place even if semantically the variables are "immutable." Heck, even Python does that with the built-in immutable types. When you assign the changed data to a new name, it doesn't actually allocate new memory and just does it in-place under the hood. In cases like that, the data isn't really "immutable." It just can't be mutated by the programmer, only by the runtime or compiler. Of course, if we want to get sufficiently pedantic, no data is ever immutable. The law may say a ledger is append-only, but nothing is stopping an accountant from just lying. A compiler may prevent you from assigning new data to an already-existing name binding, but a compiler can't stop someone from using rowhammer or an x-ray machine or something and flipping the bits in memory anyway.