Live data from Hacker News

The Future of TLA+ [pdf]

lamport.azurewebsites.net

21–30 of 107 posts

Re: The Future of TLA+ [pdf]

#21
post #18
post #5

Earlier quoted context omitted.

Limits of TLA+ - It cannot compile to working code - Steep learning curve Opportunities for TLA+ - Helps you understand complex abstractions & systems clearly. - It's extremely effective at communicating the components that make up a system with others. Let get give you a real practical example. In the AI models there is this component called a "Transformer". It under pins ChatGPT (the "T" in ChatGPT). If you are to…

Sounds similar to UML: Unified Modeling Language diagrams. I wonder if TLA+ could convert to diagrams instead of Math notation.

you are way off. These is a tool to simulate and validate systems and expose edge/race conditions of that system.

Re: The Future of TLA+ [pdf]

#22

A TLA+ alternative people might find curious. https://quint-lang.org/

What are other limits and opportunities for TLA+ and similar tools?

Formal specifications benefits are clear and I think well understood at that point. If you want to ensure that your specifications is coherent and doesn’t have unexpected behaviour, having a formal specification is a must. It’s even a legal requirement for some system nowadays in safety critical applications.

The issue of TLA+ is that it doesn’t come from the right side of the field. Most formal specifications tools were born out of necessity from the engineering fields requiring them. TLA+ is a computer science tool. It sometimes shows in the vocabulary used and in the way it is structured.

Re: The Future of TLA+ [pdf]

#23

Earlier quoted context omitted.

TLA+ is only "executable" in the same sense that an algebraic expression is executable. It's perfectly possible to write things on TLA+ that can not be simply executed linearly. (These overlap to a great extent with the things which TLC rejects.) As a basic example, it's easy to write a statement with \A (unbounded universal quantification) whose truth can only be judged by a proof engine. Specification languages are…

Being able to create systems by writing specifications and having the computer figure out how to execute them was basically the point of fifth generation programming languages. More relevant today, you can execute other "specification" languages like Coq and Idris because they support things outside the narrow feature set of specification usecases. TLA+ isn't executable and doesn't look like an imperative language be…

Coq is not a specification language. It’s an interactive theorem prover. The goal set is completely different.

Re: The Future of TLA+ [pdf]

#24

> Simplicity is a major goal of TLA+. Is TLA+ simple? I find this hard to accept. > TLA+ isn’t a programming language; it’s mathematics. Mathematics is not executable, though, whereas TLA+ is. > TLA+ [is better] for its purpose than a programming language. "TLA+ is a formal specification language designed by Leslie Lamport for the specification of system behavior." "specification of system behavior" sounds like a pro…

> Is TLA+ simple? I find this hard to accept.

It is very, very simple, and I would say easier to learn than Python, as long as you remember that it is not programming but maths. For example, suppose you specify this function on the integers:

    f ≜ CHOOSE f ∈ [Int → Int] : 
       ∀ x ∈ Int : f[x] = -f[x]
What function is it? Clearly, it's the zero function rather than what defining the equivalent "programming function" in, say, Haskell would mean:

    f :: Integer -> Integer
    f x = -(f x)
> Mathematics is not executable, though, whereas TLA+ is.

It is definitely not executable (i.e. not any more than mathematics is; you can specify executable things in maths and therefore in TLA+, but not everything you specify is executable). You can specify non-computable things (e.g. it is trivial to specify a halting oracle) as well as things involving real numbers. Moreover, when you check a TLA+ specification with a model-checker like TLC, it doesn't actually execute the specification, as it can check a specification of uncountable many executions, each of infinite length in a second.

However, you can certainly write formulas specifying the behaviour of an executable program and simulate it with TLC. But this is because you can use mathematics to describe physical systems, but not everything you can describe in mathematics can have a physical representation.

> "specification of system behavior" sounds like a programming language to me. A systems programming language, even.

A program is, indeed, one way of specifying a system, and TLA+ does allow you to specify an algorithm in this way (because maths allows you to specify programs), but it also allows you to specify systems in very useful ways that are very much not programs. For example, you can specify a component that sorts things without ever writing an algorithm for sorting, which is useful when the details of the sorting algorithm are irrelevant to the questions you want to answer. It's like how you can write a formula that treats planets as point-masses if you're interested in orbital mechanics, yet specify the earth in a much more detailed way if you're interested in predicting the weather.

> even as the language appears nowhere on the TIOBE rankings.

It is not a programming language. While it is true that far more people write programs than use mathematics to reason about physics, biology, or the way software systems behave (especially complicated interactive and distributed systems, which is where TLA+ excels), that doesn't mean such disciplines have no future.

Re: The Future of TLA+ [pdf]

#25

A TLA+ alternative people might find curious. https://quint-lang.org/

I wouldn't say it's a TLA+ alternative because it cannot do the most powerful and useful things TLA+ does (esp. refinement), but it is an alternative for programmers who just want to specify at a level that closer to code and model-check specifications.

Re: The Future of TLA+ [pdf]

#26

Earlier quoted context omitted.

Being able to create systems by writing specifications and having the computer figure out how to execute them was basically the point of fifth generation programming languages. More relevant today, you can execute other "specification" languages like Coq and Idris because they support things outside the narrow feature set of specification usecases. TLA+ isn't executable and doesn't look like an imperative language be…

Coq is not a specification language. It’s an interactive theorem prover. The goal set is completely different.

Coq, specifically Gallina, is absolutely a specification tool. It's not only that, but it's one of the big use cases it's explicitly designed to support.

Re: The Future of TLA+ [pdf]

#27

Earlier quoted context omitted.

Coq is not a specification language. It’s an interactive theorem prover. The goal set is completely different.

Coq, specifically Gallina, is absolutely a specification tool. It's not only that, but it's one of the big use cases it's explicitly designed to support.

No, it’s not. Gallina is not a specification tool in the way TLA+ is (even if coq calls it its specification language). Gallina is a language used to write mathematical statements which you intend to prove. It’s not designed to write specifications.

Coq is definitely not a specification tool. You can probably prove a specification with it in the same way you actually can do symbolic manipulation with C if you really want to. It still remains an interactive prover.

Re: The Future of TLA+ [pdf]

#28
post #24

> Simplicity is a major goal of TLA+. Is TLA+ simple? I find this hard to accept. > TLA+ isn’t a programming language; it’s mathematics. Mathematics is not executable, though, whereas TLA+ is. > TLA+ [is better] for its purpose than a programming language. "TLA+ is a formal specification language designed by Leslie Lamport for the specification of system behavior." "specification of system behavior" sounds like a pro…

> Is TLA+ simple? I find this hard to accept. It is very, very simple, and I would say easier to learn than Python, as long as you remember that it is not programming but maths. For example, suppose you specify this function on the integers: f ≜ CHOOSE f ∈ [Int → Int] : ∀ x ∈ Int : f[x] = -f[x] What function is it? Clearly, it's the zero function rather than what defining the equivalent "programming function" in, say…

> It is very, very simple, and I would say easier to learn than Python, as long as you remember that it is not programming but maths. For example, suppose you specify this function on the integers:

> f ≜ CHOOSE f ∈ [Int → Int] : > ∀ x ∈ Int : f[x] = -f[x]

> What function is it? Clearly, it's the zero function

Did you mean your example is the constant function [1], rather than a zero function [2] (where c = 0)?

[1] https://mathworld.wolfram.com/ConstantFunction.html

[2] https://mathworld.wolfram.com/ZeroFunction.html

Re: The Future of TLA+ [pdf]

#29
As someone who's fascinated by formal verification and who's early in their career, what advice do senior folks who have been using TLA+ have?

TLA+ isn't taught in most universities and while I've read about so many interesting applications, I'm yet to convince myself that someone would hire me for knowing it rather than just teaching it to me on the job. Any tips to get started would also be appreciated!

Re: The Future of TLA+ [pdf]

#30

> Simplicity is a major goal of TLA+. Is TLA+ simple? I find this hard to accept. > TLA+ isn’t a programming language; it’s mathematics. Mathematics is not executable, though, whereas TLA+ is. > TLA+ [is better] for its purpose than a programming language. "TLA+ is a formal specification language designed by Leslie Lamport for the specification of system behavior." "specification of system behavior" sounds like a pro…

> "specification of system behavior" sounds like a programming language to me

By "specification language" Lamport means one capable of verification via model checking.

In contrast, "programming languages" are not capable of such verification.

Post reply on HN