Modeling Redux with TLA+

"Would be valuable to learn that he dresses like a clown or like indiana jones in conferences and my preference on learning TLA?" Of course not. That question is too simple, and you know it! ;)

Could you also ask a question that completely gives a counter example? Could you think of a question that does help learning TLA+ because you know something about Leslie Lamport? Have it as a fun exercise for 10 minutes, or not, it might stretch your mind a bit since you claim that you can't see the relevance.

Here is why I like to know about authors who found a field:

Knowing the author may give an idea or context about TLA+. While not strictly necessary, it may be interesting background information that people don't know about. I presume that Lamport has one of the most, if not the most authentic reason for why he created TLA+ in the first place. Reading that reason may motivate people more to learn more about TLA+, or demotivate people more -- but for the right reasons!

Furthermore, discussions can be associative: gabuzome gave book recommendations written by Lamport. I didn't know Lamport wrote one (I know very little about Lamport) and since he now recommended it I'm happy to know that the founder of TLA+ also writes books worthy enough of a recommendation. It personally gives me more confidence to read it and take a crack at it.

There is some discussion on it here about TLA+ itself: https://news.ycombinator.com/item?id=14373359

Not about JavaScript though, but C and Java.

Thanks, will look into that - I read that Coq can generate Haskell etc, so I was wondering if something similar exists.

I generally agree, but formal methods I can say with confidence will get adopted in the future.

Here is why: Testing is fastly becoming adopted by everyone in our industry, why? Becuase you cannot afford to not write tests if your system is large/important enough. However our current testing methods cannot not prove the absence of bugs, as Dijkstra is fond of saying. So the best we can tell our clients currently on the bug-free/security question is this: "We wrote it according to X standard and wrote tests to cover those cases.". Formal methods allow us to prove a system is bug-free/secure. It is the evolution of testing. I do not know how far off it is, but because we have already adopted testing I believe formal methods will get adopted as well.

There is a PlusCal -> Go compiler[1] and, as I mentioned in a comment on a thread linked in another response to your question, there are tools to translate C and Java code to TLA+ for verification. But as a relatively experienced TLA+ user, I see almost no value in doing the first, and little practical value in the second.

The kind of properties you want to reason about in TLA+ are so global and fundamental, that the code you'd end up writing would both be too far removed from the high-level spec, and the process of translation would be negligible in the grand scheme of things, so that an automatic translation, if it is able to produce usable code at all, wouldn't really save you any time.

That's not to say that you shouldn't also reasons about more local properties at the code level, and there are good code-level verification tools (advanced ones include Frama-C for C, OpenJML/Krakatoa for Java and SPARK for Ada) just for that.

It is possible to use TLA+ (and other tools, like Coq or Isabelle) for what's known as end-to-end verification, which means verifying the important global properties all the way down to the code level (and even machine-code level), but the process is so laborious that it is virtually never worth the effort, and, in fact, it has never been achieved for any but very small programs (and even then at great cost).

[1]: https://github.com/UBC-NSS/pgo