Why do you care if a number is greater than 100? That has to actually mean something to you. What does it actually mean? Is it a validation error? Is it a warning trigger? Why not have a data type that actually expresses that meaning?
Wait, are you hung up on implementation nonsense? Sure, there's a low-level operation that returns a 0 or 1 that you convert into your actually-meaningful data type. But that doesn't need to have a surface language boolean type that's privileged by the language design. And that's what's important here - language design. People write programs in a language, not compiled code. The model the language provides is of critical importance. It's how the users of the language think and how they communicate with each other.
And this isn't abstraction. Boolean is the abstraction. It throws away all but a single bit of information. This is creating data types with semantics that carry far more than that single bit. It's making your code less abstract.
You could make a battle royal game well where people start taking damage when they are 100 units away from the center of the map.
>Why not have a data type that actually expresses that meaning?
It would add unneccessary complexity.
>Wait, are you hung up on implementation nonsense?
The base of what it being abstracted over is not nonsense.
>But that doesn't need to have a surface language boolean type that's privileged by the language design.
If exposing booleans lets people write simpler code then it makes sense to expose it instead of forcing complexity onto everything.
>Boolean is the abstraction.
No, booleans are a concept that the processor understands. Zero is false and nonzero is true. The processor has instructions like like logical and that can operate on these booleans. Branches can happen based off a bit in the status register. A bit has two states which maps to true and false. Booleans are a fundamental concept that is being built upon. The processor has a limited number of data types that it understands. Creating new data types is creating abstractions because those data types do not actually exist. You are simply hiding an actual data type in the new one you are creating.
> You could make a battle royal game well where people start taking damage when they are 100 units away from the center of the map.
So... You have some meaning there, don't you? Something beyond the values true or false? Does true mean "is safe" or "is taking damage"? Wouldn't something that actually says what you mean be a lot clearer? More direct? Fewer ideas between the expression and the meaning? Less abstract?
> If exposing booleans lets people write simpler code then it makes sense to expose it instead of forcing complexity onto everything.
Why do you think it's more complex to eliminate a semantic step?
Your last paragraph is... very weird. Do you think languages are required to privilege Boolean over any other 2-type, such that only Booleans are allowed to map to those values in machine code? Not every language is as poorly designed as C. You're not wrapping Booleans, you're creating new types which the compiler gives the exact same representation as Booleans get.
And for what it's worth, processors don't understand zero and one. They're mechanistic circuits that operate on combinations of high and low voltages. Zero and one are interpretations added on top of what's going on. If it's easier to think of high voltage as one and low voltage as zero, maybe it's even easier to think of them as "safe" and "taking damage".
You could name a function that returns a boolean isInSafeZone. From the name it would be clear that true means safe and false means that it isn't.
>Wouldn't something that actually says what you mean be a lot clearer
No, compare "if (player.isInSafeZone())" to "if (player.getSafeZoneState() == SafeZoneState.SAFE)". Endure is extra verbosity that isn't giving you value.
>Fewer ideas between the expression and the meaning?
I don't know what you mean by this. You are creating extra types for every possible condition is introducing more ideas. Why have 1000 boolean types when you can have 1 that interopts with itself.
>Why do you think it's more complex to eliminate a semantic step?
There is more steps in creating a new type, maintaining it, and having to convert it into what you want when you could just use booleans from the start.
>Do you think languages are required to privilege Boolean over any other 2-type
No, even C has typedef. I never implied there was wrapping going on. I meant that you are introducing layers of indirection. It's a case of everything in programming can be solved by creating an interaction except having too many indirections. Indirection is not always the answer even if there is no performance impact.
>processors don't understand zero and one
By the interface that is exposed to programmers they do. Read the manual. For the purposes of making a programming language there is no benefit in going down to the level of voltages. It is an implementation detail that is the processor creator's job to worry about.
Wait, are you hung up on implementation nonsense? Sure, there's a low-level operation that returns a 0 or 1 that you convert into your actually-meaningful data type. But that doesn't need to have a surface language boolean type that's privileged by the language design. And that's what's important here - language design. People write programs in a language, not compiled code. The model the language provides is of critical importance. It's how the users of the language think and how they communicate with each other.
And this isn't abstraction. Boolean is the abstraction. It throws away all but a single bit of information. This is creating data types with semantics that carry far more than that single bit. It's making your code less abstract.