8 ms·

This idea can be extended by observing the following analogy: purity is to functions as immutability is to data Immutability is definitely a valuable techni

This idea can be extended by observing the following analogy: purity is to functions as immutability is to data Immutability is definitely a valuable technique that can help make software faster (sometimes), more reliable, and easier to maintain. I would take it one step further and argue that we can get a similar boost by extending the idea to functions, not just data. And the way you do that is by writing pure functions (i.e. no side effects...or controlling/limiting them in some way) and using languages that can enforce that your functions are pure.

sitkack 5y ago
Yes, and computation and data both become interchangeable facts. And by becoming facts, they lessen the tech debt, and start to fade into the background. I think the only way to have tractable large systems is to have pervasive immutability and purity.
jhgb 5y ago
> purity is to functions as immutability is to data I thought all data was just a bunch of nullary functions. ;)
tsimionescu 5y ago
Unfortunately, this just doesn't pan out in practice. There are various techniques that are much more inefficient to express with immutability and pure functions (e.g. computing a histogram). There is also a pretty big body of evidence already that doesn't show any hugely significant (say, 2x) changes in productivity, correctness or speed for using pure, strict functional languages and styles vs more traditional imperative, impure or even dynamic languages.
- benrbray 5y ago
  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...

sitkack 5y ago

Yes, and computation and data both become interchangeable facts. And by becoming facts, they lessen the tech debt, and start to fade into the background. I think the only way to have tractable large systems is to have pervasive immutability and purity.

jhgb 5y ago

> purity is to functions as immutability is to data I thought all data was just a bunch of nullary functions. ;)

tsimionescu 5y ago

Unfortunately, this just doesn't pan out in practice. There are various techniques that are much more inefficient to express with immutability and pure functions (e.g. computing a histogram). There is also a pretty big body of evidence already that doesn't show any hugely significant (say, 2x) changes in productivity, correctness or speed for using pure, strict functional languages and styles vs more traditional imperative, impure or even dynamic languages.

benrbray 5y ago
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...