Re:Practical TLA+
by markdoubleyou on Thursday October 18, 2018 @07:16PM
(#18253154)
Yes, very helpful, thank you! I'd like to see methods like this go mainstream. The prevalent view these days seems to be that software construction begins and ends with unit tests... I don't know how Uncle Bob and his ilk managed to drown out all of the other approaches to construction, but it's always bothered me that even lightweight approaches to verification (like Design by Contract) haven't gotten the same traction. (I suspect it's because formal verification involves more requirements gathering and design work up front, but a lot of teams short-change that because "we're doing agile!!")
Anyway, thank you for putting this out there. I took a look at your first couple of chapters on Safari and your treatment of the subject is much more approachable to me than the wall of math I encountered in Leslie Lamport's stuff.
* A few different groups verified business ETLs with it, finding corner cases which would lose or corrupt data. Similarly, I a lot of use for deployment procedures.
* A lot of people are using it for testing optimizations: write a TLA+ spec of your system, write a spec of the optimizations, and check that they have the same behavior.
* Finding bugs in microservices. I get a _ton_ of emails about this.
* Lots of specific domain problems: trading algorithms, robotics, etc.
The main benefit of TLA+ (and formal specification in general) is that it gives you a way of both writing a precise design of your system and checking the design itself for bugs. That's something so rare in mainstream programming that many people don't even know it's possible. That's why I want to make this stuff more accessible.
Does that answer your question?