Funny, I'd say that writing proofs is a lot like building an airplane, and software engineering might be far away from both.
In writing a proof, you provide an argument that justifies some claim is true. Your argument has to be airtight, so that no matter what kind of counter example or ugly scenario is proposed, your argument still holds.
The same seems true for an airplane. It needs to do its job (fly) and do so on the face of a myriad of different external factors. If you build a plane, it should "never" fail.
Software on the other hand, can be built without thinking about ALL of these edge cases. Obvious it's better if it always works, but it's usually okay if there is some bizarre scenario that causes an error. For some pieces of software it might even be okay if these errors never get fixed (ie: a very small number of users ever experience them). Software can work, even when it (kinda) doesn't.
The Curry-Howard correspondence might be technically true, but we're just as bad at writing specifications for programs as we are at writing the programs themselves. It could be good to acknowledge that and just write the software that solves most, but maybe not all, of our problems.
In writing a proof, you provide an argument that justifies some claim is true. Your argument has to be airtight, so that no matter what kind of counter example or ugly scenario is proposed, your argument still holds.
The same seems true for an airplane. It needs to do its job (fly) and do so on the face of a myriad of different external factors. If you build a plane, it should "never" fail.
Software on the other hand, can be built without thinking about ALL of these edge cases. Obvious it's better if it always works, but it's usually okay if there is some bizarre scenario that causes an error. For some pieces of software it might even be okay if these errors never get fixed (ie: a very small number of users ever experience them). Software can work, even when it (kinda) doesn't.
The Curry-Howard correspondence might be technically true, but we're just as bad at writing specifications for programs as we are at writing the programs themselves. It could be good to acknowledge that and just write the software that solves most, but maybe not all, of our problems.