4 ms·

I would take the FP zealots more seriously if they stopped asserting that FP makes things more correct. Zero evidence that this is the case. I can tell you th

I would take the FP zealots more seriously if they stopped asserting that FP makes things more correct. Zero evidence that this is the case. I can tell you that debugging a compiler written in ML is a dumpster fire compared to debugging a compiler written in C++. If take C++ over any FP language for compilers any day of the week.

yawaramin 1y ago
OCaml is not just FP. It's FP + strong static typing + modular programming + exhaustive pattern matching + fast compiles + great set of built-in compiler lints (eg unused code warnings, mutation warnings). All of these things together help write very reliable code.
- pizlonator 1y ago
  There is no evidence that any of those things lead to more correctness. It’s all feels
  - yawaramin 1y ago
    There's plenty of evidence. Here's the OCaml compiler catching a redundant rule in the Unicode line-breaking algorithm: https://www.unicode.org/mail-arch/unicode-ml/y2020-m03/0000.html https://www.unicode.org/mail-arch/unicode-ml/y2020-m03/0000.... People who like rejecting this kind of stuff as 'feels' are ironically also being guided by their 'feels'.
    - differentmod 1y ago
      Do you have any thoughts on my other post in this comment section? https://news.ycombinator.com/item?id=44699548 https://news.ycombinator.com/item?id=44699548
    - pizlonator 1y ago
      One example of a compiler catching some issue isn't evidence. It's an anecdote. There's no scientific experiment you could run that proves, or disproves, that type systems lead to more correctness. It's a thing you cannot possibly know.
      - yawaramin 1y ago
        We already have scientific experiments that prove it. Here is a significant result: https://ieeexplore.ieee.org/document/7985711 https://ieeexplore.ieee.org/document/7985711 This is why I say that people who keep denying this are vibing based on their feels. Instead of asking for the evidence they just keep saying there can't possibly be any evidence.
- johnisgood 1y ago
  For those who do not know, OCaml is multi-paradigm. You can do OOP and imperative in OCaml as well, not just FP. In a typical codebase, you may find a combination of all styles.
pjmlp 1y ago
Yet all mainstream languages, including C++, keep adding FP concepts. Better spend some time having fun with std::variant, visit, and ranges transformers.
- deleted 1y ago
  [deleted]
differentmod 1y ago
> I would take the FP zealots more seriously if they stopped asserting that FP makes things more correct. Depends on the correctness requirements in question. But overall you are 100% correct about this. FP, among other aspects, enables and promotes some ways of reasoning, for instance when mutation is avoided, that can be relatively easy to use to verify correctness of certain types of properties. For instance, induction proofs and some other kinds of mathematical proofs. However, for some other types of correctness properties, imperative programming can be easier to reason about than FP. One possible example is in regards to implementation of algorithms, where for instance an implementation of quicksort in C is likely to be more concise and clearer than a "true" quicksort implementation in Haskell. Another possible example is (if one assumes that FP requires garbage collection) that of hard real-time systems, for instance some types of medical devices, where even though some types of garbage collection may be viable, approaches like forgoing dynamic memory allocation (no malloc, no reference counting, no types of garbage collection, etc.) may be easier to reason about regarding achieving the correctness requirement of hard real-time. Overall, I definitely agree that ML and FP are not the best for achieving correctness in all cases. I personally like to pick and choose between FP and other approaches, and mix them in different ways dependent on the project or task at hand. Like, a purely functional interface with internal mutation in the implementation for optimization. Or, some mutable API that uses FP for some aspects of the implementation where FP is easier to reason about. > I can tell you that debugging a compiler written in ML is a dumpster fire compared to debugging a compiler written in C++. If take C++ over any FP language for compilers any day of the week. For larger compilers for some requirements, I could for some projects imagine that this is true. But, for smaller compilers with relatively few requirements, the pattern matching and tagged union features of modern ML languages are very popular, and I like having access to those features when writing smaller compilers. If you do not mind spending the time to expound on this topic, I would very much like to know more. Or, maybe some links, like blog posts, that discuss this topic. I am genuinely curious. A blog post could also be shared elsewhere, instead of just lost in some Hacker News discussion. (Maybe I should start blogging myself). Also, Hacker News/Ycombinator is censorship-infested.
- deleted 1y ago
  [deleted]

yawaramin 1y ago

OCaml is not just FP. It's FP + strong static typing + modular programming + exhaustive pattern matching + fast compiles + great set of built-in compiler lints (eg unused code warnings, mutation warnings). All of these things together help write very reliable code.

pizlonator 1y ago
There is no evidence that any of those things lead to more correctness. It’s all feels
- yawaramin 1y ago
  There's plenty of evidence. Here's the OCaml compiler catching a redundant rule in the Unicode line-breaking algorithm: https://www.unicode.org/mail-arch/unicode-ml/y2020-m03/0000.html https://www.unicode.org/mail-arch/unicode-ml/y2020-m03/0000.... People who like rejecting this kind of stuff as 'feels' are ironically also being guided by their 'feels'.
  - differentmod 1y ago
    Do you have any thoughts on my other post in this comment section? https://news.ycombinator.com/item?id=44699548 https://news.ycombinator.com/item?id=44699548
  - pizlonator 1y ago
    One example of a compiler catching some issue isn't evidence. It's an anecdote. There's no scientific experiment you could run that proves, or disproves, that type systems lead to more correctness. It's a thing you cannot possibly know.
    - yawaramin 1y ago
      We already have scientific experiments that prove it. Here is a significant result: https://ieeexplore.ieee.org/document/7985711 https://ieeexplore.ieee.org/document/7985711 This is why I say that people who keep denying this are vibing based on their feels. Instead of asking for the evidence they just keep saying there can't possibly be any evidence.
johnisgood 1y ago
For those who do not know, OCaml is multi-paradigm. You can do OOP and imperative in OCaml as well, not just FP. In a typical codebase, you may find a combination of all styles.

pjmlp 1y ago

Yet all mainstream languages, including C++, keep adding FP concepts. Better spend some time having fun with std::variant, visit, and ranges transformers.

deleted 1y ago
[deleted]

differentmod 1y ago

> I would take the FP zealots more seriously if they stopped asserting that FP makes things more correct. Depends on the correctness requirements in question. But overall you are 100% correct about this. FP, among other aspects, enables and promotes some ways of reasoning, for instance when mutation is avoided, that can be relatively easy to use to verify correctness of certain types of properties. For instance, induction proofs and some other kinds of mathematical proofs. However, for some other types of correctness properties, imperative programming can be easier to reason about than FP. One possible example is in regards to implementation of algorithms, where for instance an implementation of quicksort in C is likely to be more concise and clearer than a "true" quicksort implementation in Haskell. Another possible example is (if one assumes that FP requires garbage collection) that of hard real-time systems, for instance some types of medical devices, where even though some types of garbage collection may be viable, approaches like forgoing dynamic memory allocation (no malloc, no reference counting, no types of garbage collection, etc.) may be easier to reason about regarding achieving the correctness requirement of hard real-time. Overall, I definitely agree that ML and FP are not the best for achieving correctness in all cases. I personally like to pick and choose between FP and other approaches, and mix them in different ways dependent on the project or task at hand. Like, a purely functional interface with internal mutation in the implementation for optimization. Or, some mutable API that uses FP for some aspects of the implementation where FP is easier to reason about. > I can tell you that debugging a compiler written in ML is a dumpster fire compared to debugging a compiler written in C++. If take C++ over any FP language for compilers any day of the week. For larger compilers for some requirements, I could for some projects imagine that this is true. But, for smaller compilers with relatively few requirements, the pattern matching and tagged union features of modern ML languages are very popular, and I like having access to those features when writing smaller compilers. If you do not mind spending the time to expound on this topic, I would very much like to know more. Or, maybe some links, like blog posts, that discuss this topic. I am genuinely curious. A blog post could also be shared elsewhere, instead of just lost in some Hacker News discussion. (Maybe I should start blogging myself). Also, Hacker News/Ycombinator is censorship-infested.

deleted 1y ago
[deleted]