Re:Correctness – A paradigm for sustainable software develop...
by jes5199 on Friday April 05, 2019 @09:52PM
(#19588652)
this is how you end up with darcs as your version control system. It’s provably correct, but about 1 in 10 times it hangs forever and never terminates. Also it doesn’t implement branching because that’s out of scope for the model.
Re:Correctness – A paradigm for sustainable software develop...
by nickpsecurity on Saturday April 06, 2019 @10:05AM
(#19590764)
Nah, it's how you end up with HACL*: verified crypto that performs like C shipping in Firefox.
https://github.com/project-everest/hacl-star
You can verify stupid designs or smart ones. You can do impractical verification or pragmatic approaches. Formal verification is a tool whose outcomes depend on who wields it. The only consistent drawbacks it has are requiring more expertise, the project takes longer, and the project has to be simplified in design/implementation. High-quality software in general (eg OpenBSD) often has same properties, though. Possibly intrinsic to achieving correctness rather than additional requirement of formal methods.
Re:Correctness – A paradigm for sustainable software develop...
by viraptor on Saturday April 06, 2019 @07:03AM
(#19590207)
I think you're mixing the result of implementation and the way something's implemented. Darcs relies on abstract theory which implemented didn't end up very performant or full of features. But it would be close to the same speed if it was implemented in terrible C. On the other hand you can write provable implementation of git with similar speed as the current one.
https://www.quora.com/Why-is-functional-programming-suited-f...
Functional programming is also easier to mathematically verify than imperative:
https://semantic-domain.blogspot.com/2018/04/are-functional-...
While you might not do proof, languages and methods that are easier for proof are often easier for automated analyses that look for problems, too. There's tools out there that can check code for concurrency problems that are extremely hard to spot with just testing. They might be easier to build or get more results if the program was functional/stateful instead of heavily stateful.