Lamport didn't design TLA+ for model checking or for practicing developers to use. He did purely for publishing papers where the researchers express their proofs as math (his new TLA+) instead of free form text.
TLA+ was specifically designed for practitioners (https://lamport.azurewebsites.net/tla/book.html), although he did use earlier incarnations of TLA to analyse his own concurrent and distributed algorithms.
His paper explaining TLA [1] says:
> We are motivated not by an abstract ideal of elegance, but by the practical problem of reasoning about real algorithms. Rigorous reasoning is the only way to avoid subtle errors in concurrent algorithms, and we want to make reasoning as simple as possible by making the underlying formalism simple.
The introduction to the book says:
> TLA provides a mathematical foundation for describing systems. To write specifications, we need a complete language built atop that foundation. I ini- tially thought that this language should be some sort of abstract programming language whose semantics would be based on TLA. I didn’t know what kind of programming language constructs would be best, so I decided to start writing specifications directly in TLA. I intended to introduce programming constructs as I needed them. To my surprise, I discovered that I didn’t need them. What I needed was a robust language for writing mathematics.
> Although mathematicians have developed the science of writing formulas, they haven’t turned that science into an engineering discipline. ... The specification of a real system can be dozens or even hundreds of pages long. Mathematicians know how to write 20-line formulas, not 20-page formulas. So, I had to introduce notations for writing long formulas. What I took from programming languages were ideas for modularizing large specifications.
And the Getting Started portion says:
> A system specification consists of a lot of ordinary mathematics glued together with a tiny bit of temporal logic. That’s why most TLA+ constructs are for expressing ordinary mathematics. To write specifications, you have to be familiar with this ordinary math. Unfortunately, the computer science departments in many universities apparently believe that fluency in C++ is more important than a sound education in elementary mathematics. So, some readers may be unfamiliar with the math needed to write specifications. Fortunately, this math is quite simple. If exposure to C++ hasn’t destroyed your ability to think logically, you should have no trouble filling any gaps in your mathematics education.
He recognises the tradeoffs of abandoning the programming style, but it is done to make the language simple and practitioner-friendly (and it is a much simpler language than Python, let alone any other specification language, all while preserving maximal expressive power). You can have an opinion on whether this is a good tradeoff or not, but it was done intentionally, and with the purpose of helping practitioners.
pron|7 months ago
His paper explaining TLA [1] says:
> We are motivated not by an abstract ideal of elegance, but by the practical problem of reasoning about real algorithms. Rigorous reasoning is the only way to avoid subtle errors in concurrent algorithms, and we want to make reasoning as simple as possible by making the underlying formalism simple.
The introduction to the book says:
> TLA provides a mathematical foundation for describing systems. To write specifications, we need a complete language built atop that foundation. I ini- tially thought that this language should be some sort of abstract programming language whose semantics would be based on TLA. I didn’t know what kind of programming language constructs would be best, so I decided to start writing specifications directly in TLA. I intended to introduce programming constructs as I needed them. To my surprise, I discovered that I didn’t need them. What I needed was a robust language for writing mathematics.
> Although mathematicians have developed the science of writing formulas, they haven’t turned that science into an engineering discipline. ... The specification of a real system can be dozens or even hundreds of pages long. Mathematicians know how to write 20-line formulas, not 20-page formulas. So, I had to introduce notations for writing long formulas. What I took from programming languages were ideas for modularizing large specifications.
And the Getting Started portion says:
> A system specification consists of a lot of ordinary mathematics glued together with a tiny bit of temporal logic. That’s why most TLA+ constructs are for expressing ordinary mathematics. To write specifications, you have to be familiar with this ordinary math. Unfortunately, the computer science departments in many universities apparently believe that fluency in C++ is more important than a sound education in elementary mathematics. So, some readers may be unfamiliar with the math needed to write specifications. Fortunately, this math is quite simple. If exposure to C++ hasn’t destroyed your ability to think logically, you should have no trouble filling any gaps in your mathematics education.
He recognises the tradeoffs of abandoning the programming style, but it is done to make the language simple and practitioner-friendly (and it is a much simpler language than Python, let alone any other specification language, all while preserving maximal expressive power). You can have an opinion on whether this is a good tradeoff or not, but it was done intentionally, and with the purpose of helping practitioners.
[1]: https://lamport.azurewebsites.net/pubs/lamport-actions.pdf