Earlier quoted context omitted.
For software engineers specifically -- every time you are coding formalized programmatic logic, you are using math. If you took a logics and proofs course, it would help you formalize logic better. Every time you write a "for" loop you are essentially using summations. There is a book called Concrete Mathematics and one of the primary authors is Donald Knuth, basically it's "Programmers math" and in my opinion, would…
You seem to describe a very different world of programming than the one I live in. I have no dislike for logic, formal proofs, category theory and such: I can live in that world just fine. However, almost none of the problems I've ever had to dealt with in my 15 years programming made me wish for large amounts of that: I've used bits here and there, but going all in never made any sense. The hard part of most tasks I…
> Great!... Except, not so, because his proof only worked in a mythological environment where there is no latency between nodes. Under real conditions, the algorithm's properties led to unacceptable results, and he just hid behind the proof.
Then he did a bad job. His failure does not undermine the power of taking a formal approach to a problem. He should have accounted for this latency in his initial model. What he did is the equivalent of someone working on an autonomous car and assuming that a noisy GPS signal is good enough to do control with.