Off the top of my head. Compilers. You may know that a value has known 1s and 0s and unknowns. This would allow you to represent that for optimisation purposes.

Arturo[0] language supports true,false and maybe. I really liked that idea actually, worth mentioning here.

so valid arturo code can be like (picked from their in-a-nutshell documentation)

i1: true

i2: false

i3: maybe

[0]: https://arturo-lang.io/documentation/in-a-nutshell

Everyone hates null but (in database land, and arguably in other programming) it just means “no data.”

(As an aside, I found the characterisation of null as being a “billion dollar mistake” to be unfair. Those who don’t acknowledge null are doomed to reimplement it, probably poorly, or to have the unknowns in their logic remain unknown unknowns.)

The "mistake" was not in providing a way to represent "no data", it was in providing no way to represent "this definitely HAS" data.

Languages that correct the problem have two separate types (eg: Foo & Option<Foo>) meaning "definitely a Foo" and "a Foo but it might have no data". Java just has Foo, meaning "a Foo but it might have no data" but no way to represent "definitely a Foo".

Had a good chuckle

If it weren't for Bool as a name, that's just 0 for OK, non-zero for errors with 1 being general failure.

TDWTF code is usually hyperbolized. It might not have been called Bool.

But also it could have been found in the wild in C/C++ code, which both had no "native" Boolean type until surprisingly recently (C++17 and C23! as in 2017 and 2023 standards, irrespectively) so Bool is very much a possible real name and not part of the hyperbole.

I've seen this pattern repeated in a number of large production codebases using optional booleans.

I want an LLM trained on dailywtf code