The Future of TLA+ [pdf]

    THEOREM fIsTheZeroFunction ≜
         f = [x ∈ Int ↦ 0]
    PROOF
      ⟨1⟩ DEFINE zero[x ∈ Int] ≜ 0
      ⟨1⟩1. ∃ g ∈ [Int → Int] : ∀ x ∈ Int : g[x] = -g[x] BY zero ∈ [Int → Int]
      ⟨1⟩2. ∀ g ∈ [Int → Int] : (∀ x ∈ Int : g[x] = -g[x]) ⇒ g = zero OBVIOUS
      ⟨1⟩3. QED BY ⟨1⟩1, ⟨1⟩2 DEF f

You can then use that proof like so:

    THEOREM f[23409873848726346824] = 0 
       BY fIsTheZeroFunction

Writing deductive proofs like above can be tedious when they're not so simple, and the TLA+ toolbox contains another tool, called TLC, that can automatically verify certain propositions (with some caveats), especially those that arise when specifying computer systems (though it cannot automatically prove that f is zero everywhere).

So the purpose of my example wasn't to show something that is useful for engineers in and of itself, but to show that TLA+ works very differently from programming languages, and it is useful for different things: not to create running software but to answer important questions about software.

But TLA+'s past, present, and future, is as a language for writing mathematical specifications. When you compare it to other languages for writing mathematics, like Coq or Lean, you will see that it is, indeed, much more approachable and orders of magnitude easier to learn. Writing mathematics in Python syntax is not only foreign but also quite inapproachable and confusing, because the meaning of things like functions and operators are so different in Python and mathematics. Using the same syntax for things that work very differently is not helpful.[1]

Now, TLA+ is not a programming language, it's not trying to compete with programming language, and like mathematics in general, it can never hope to have as many practitioners as there are programmers. It is, however, already the most popular language for writing mathematical specification of software and hardware, because programmers and hardware designers can learn and apply it much quicker than they can Lean or Coq.

Not every programmer is interested in using mathematics to specify digital systems, but some fund it very useful, and for some it's even necessary.

> The TLA+ community can not have it both ways, either stop bemoaning the lack of adoption of formal verification, or adapt to meet people where they are at.

You do have a point, but it's complicated. Mathematics is inherently more expressive than programming, and so there are often specifications that are simply much easier to write in maths than in a programming language. Writing maths in programming-language syntax is not helpful and is even a hindrance, and the problem is that it's not that a lot of programmers don't want to learn mathematical syntax; they just don't want to learn that discipline. and that's fine; I'm not currently interested in learning Japanese, but it's not because written Japanese uses symbols that are unfamiliar to me. Even if I could learn Japanese using the Latin alphabet, I'm not sure it would make things significantly easier; at best it would make things slightly easier at the cost of me not being able to employ Japanese as much in practice.

So formal methods have a choice between specifying with programming language -- which makes the method more easily adoptable by programmers but makes some very useful specifications impossible -- or use mathematics to allow people to write simpler, shorter, and more powerful specifications, but require them to learn the basics of specifying with mathematics.

What do we do? Both! There are specification languages that aim to be programming languages (or similar to programming, and somebody here mentioned Quint, which is one of the languages that do just that), and there are specification languages that are simpler and more powerful, but they are very much not programming and they don't resemble programming, and TLA+ is a language like that.

> Are you trying to build something and invite others?

Yes.

> Or are you trying to prove your own intellect?

People speaking German aren't trying to prove their intellect, it's just that I have never learnt it. There is no more intellect in using basic mathematics to specify things than in programming. If anything, I think programming is much more difficult (of course it's more common, largely due to economic incentives). But the disciplines are different. There is no more intellect in writing newspaper columns than in writing Python programs, but they are not the same, and if you want to do both you'd need to learn both.

> To whom and what for?

To those who are interested in the most powerful way to reason about the behaviour of engineered systems and are willing to spend a couple of weeks learning something that is very much outside the discipline of programming to do so. Having a tool that allows you to do that is important. I learnt TLA+ over 10 years ago when I was designing a protocol for a distributed system and ran into some subtle and dangerous bugs. TLA+ was then, and is now, the tool that most cheaply and easily allowed me to find the flaw in my algorithm and verify that an improved algorithm doesn't suffer from it. If you're using AWS directly or indirectly, you are using software that was designed with the help of TLA+.

TLA+ is not for every programmer simply because not every programmer writes software that TLA+ is the best tool to assist with, but I think that more people could find TLA+ helpful than they realise. But TLA+ is so helpful in those cases because it can be much more expressive than anything that could be expressed in a programming language.

Others may certainly find more programming-like specification languages more useful, and that's great, too! The more people know how to use various formal methods and when each may be more or less applicable, the better software will become.

[1]: Here's an example where TLA+ syntax is similar to programming:

    A(x, y) ≜ x + y

   A(x, y)' = 3

Thanks again!

That said, since non-deterministic choices are equi-probable in P, failure conditions are triggered at much higher frequencies than in a conventional testing scenario.