4 ms·

Everyone makes this point about correctness, but I have never seen an easy to understand illustration of this. Now I am by no means a leet programmer but I have

Everyone makes this point about correctness, but I have never seen an easy to understand illustration of this. Now I am by no means a leet programmer but I have been reading about programming for more than a decade and every article about this point feels confusing. I even tried writing small stuff in haskell, still don't get this point.

alisonkisk 6y ago
Correctness is only an interesting problem when it's not easy to underst example and. Easy bloggable examples aren't complex enough to be correctness challenges
- newswasboring 6y ago
  Ok. Then what book can I read to understand this. I've read two books on haskell but they were beginner stuff though
  - ghc 6y ago
    Closest I can think of is Purely Functional Data Structure (Chris Okasaki) or Category Theory for Programmers (Bartosz Milewski), but they're not exactly what you're after. I would submit that this paper from FB is more in the vein of what you're looking for: https://research.fb.com/wp-content/uploads/2020/08/Eliminating-Bugs-with-Dependent-Haskell-Experience-Report.pdf https://research.fb.com/wp-content/uploads/2020/08/Eliminati... . This interview might also be insightful: https://www.microsoft.com/en-us/research/podcast/functional-programming-languages-pursuit-laziness-dr-simon-peyton-jones/ https://www.microsoft.com/en-us/research/podcast/functional-... The truth is that Haskell is still very academically focused, so you're likely to see papers of substance much more often than books or blog posts. When you hire people to write Haskell there's two groups that always show up: young enthusiasts who are frustrated with imperative programming in their (usually first or second) day job, and academics who got transplanted into industry to work on hard problems. I've interviewed people doing formal verification of CPU circuits at Intel, people who work on compilers, people who work on verifying termination of programs (for missile guidance), and people who work on financial institution backends. What I haven't seen is too many experienced, pragmatic engineers (rather than computer scientists) who have spent their career writing Haskell.

alisonkisk 6y ago

Correctness is only an interesting problem when it's not easy to underst example and. Easy bloggable examples aren't complex enough to be correctness challenges

newswasboring 6y ago
Ok. Then what book can I read to understand this. I've read two books on haskell but they were beginner stuff though
- ghc 6y ago
  Closest I can think of is Purely Functional Data Structure (Chris Okasaki) or Category Theory for Programmers (Bartosz Milewski), but they're not exactly what you're after. I would submit that this paper from FB is more in the vein of what you're looking for: https://research.fb.com/wp-content/uploads/2020/08/Eliminating-Bugs-with-Dependent-Haskell-Experience-Report.pdf https://research.fb.com/wp-content/uploads/2020/08/Eliminati... . This interview might also be insightful: https://www.microsoft.com/en-us/research/podcast/functional-programming-languages-pursuit-laziness-dr-simon-peyton-jones/ https://www.microsoft.com/en-us/research/podcast/functional-... The truth is that Haskell is still very academically focused, so you're likely to see papers of substance much more often than books or blog posts. When you hire people to write Haskell there's two groups that always show up: young enthusiasts who are frustrated with imperative programming in their (usually first or second) day job, and academics who got transplanted into industry to work on hard problems. I've interviewed people doing formal verification of CPU circuits at Intel, people who work on compilers, people who work on verifying termination of programs (for missile guidance), and people who work on financial institution backends. What I haven't seen is too many experienced, pragmatic engineers (rather than computer scientists) who have spent their career writing Haskell.