It usually starts with one boolean.

Then people avoid touching it when expending a bit, so they just add another boolean for the corner case they're dealing with (potentially as an optional last param). And so on, until someone refactors the whole function bearing the burden to retouch all its legacy that accumulated up to that point.

It usually starts with "is_car", a simple, clear, yes or no. and then at some point someone needs to also check if it's a sedan and instead of turning it into an enum called vehicle_type an "is_sedan" is added, etc.

The other side of the coin is making an enum and eventually realizing that some of the types can overlap. I prefer the "set of tags" approach due to its flexibility.

Can't developers just... not do that? You can write bad code in any language. What is our responsibility as experts to avoid doing things like this, then?

if they know better and have the foresight, they do. But stuff like this might not occur to people who've never been bitten by it. Every step of the way you just make things a little bit messier than before.

My friend, I'd love to give you a tour of our codebase.

Unfortunately, yes

Oh gawd yes they do!

> You can think of booleans as a built-in, two-value enum that has a common semantic meaning.

I love it when a language's bool type is just a sum-type like the sum-types you define in user code, e.g. https://ocaml.org/manual/5.2/core.html#hevea_manual10. It's an indicator of a language with good foundations.

I agree. Nim’s booleans are an enum too: https://nim-lang.org/docs/system.html#bool