[amw-zero]

Have to jump in on a TLA+ comment, especially one about how it handles “types.” I say this all over the Internet - the way that TLA+ handles types is the absolute ideal from the programmer’s perspective - there is nothing special about them! No special syntax, semantics, nothing. It’s all the same language and logic, unlike most type systems which have a completely separate type language with subtly different semantics.

The problem is, that programmer simplicity pushes the complexity to the type checking. You can’t statically check TLA+ types, you have to model check them which is much more intensive.

Maybe there’s a happy medium.

[erichocean]

> You can’t statically check TLA+ types

I wish I could someday meet a programmer who's main problem, daily, is that their code won't type check. Otherwise, everything's great!

I like type checking, but not because the static type checker helps me write correct code. (When it does, the "bugs" it finds are trivial, at the same level as the syntax checker.)

I like type checking because it makes documentation easier, it makes writing code easier (code completion), because it means I can write fewer comments, etc. Not because of "correctness", and since that's the goal of something like TLA+, I haven't (yet) found myself wishing for it.

Especially with my experience using Coq, the way TLA+ handles types is a breath of fresh air. Simply lovely.

[amw-zero]

The trivial bugs that type systems are catching are in the most basic type systems that we know about. Types are not just what is present in Java, types are any proposition that can be made about a program before program execution. The propositions that a type system allows you to make is a design decision as well as an implementation challenge.

But if you look at something like F* or Idris, the types allow extremely rich propositions. I think you’re selling types short, even though they of course are not the answer to all problems.

[erichocean]

> types are any proposition that can be made about a program before program execution

How are those types any different than outright stating a behavioral invariant? (I agree that's useful, I'm just not convinced that type systems are the most user-friendly way to state system invariants vs. normal, boring mathematics.)

With languages like Idris, I feel like—because all you have are types (read: hammers)—"everything looks like a nail." But perhaps that's just me.

[amw-zero]

> How are those types any different than outright stating a behavioral invariant?

Because the behavior of programs can't be verified without executing the program, but types can be checked purely based on syntax. There is way less source code than runtime states of any non-trivial program.

I've asked this same question many times, the TLA+ way is much more expressive and _simpler_. But model checking is a way harder problem than type checking, in general. SMT solvers make this line blurry - in fact, have you heard of the SMT-based model checker for TLA+, [Apalache](https://apalache.informal.systems/)?. I haven't tried it out, but that should be way faster than TLC which just brute forces the state-space exploration.

I'm totally with you about TLA+ style spec properties, but it's a big theoretical hurdle to cross before they could be as efficient as types.