bool and int

[Chris Angelico]

On Thu, 26 Jan 2023 at 03:19, <2QdxY4RzWzUUiLuE at potatochowder.com> wrote:
> > Strongly disagree. There is PLENTY of practical value in using
> > booleans as numbers. This is nothing to do with counting bytes, and
> > everything to do with how useful it is in practice.
>
> IMO, the difference in readability between
>
>     autothrust_last_dv *= AT_mode == AT.Idle;
>
> and
>
>     if(AT_mode != AT.Idle)
>         autothrust_last_dv = 0;
>
> outweighs the practicality, whether C, C#, Java, or Python (ignoring the
> insignificant differences in syntax).

Yeah, that example was completely synthetic and not really a good
showcase. But what often comes up is either multiplying a string by a
boolean (equivalent to "have this string if this is true") or
subscripting something with a boolean.

> I could argue that the only reason the first one is readable at all is
> that we've both been exposed to languages where fanatics assume that
> True is 1 and False is 0.

I'm fine with any definition as long as it's dependable.

> I've also written low-level code with
> hardware fanatics who insist that True is 0 and False is -1 (or 255,
> depending on how much math they know).

BASIC was like that too, although it (at least, the versions I used in
my childhood) didn't have "True" and "False", you just got the actual
values -1 and 0. They were the other way around compared to what
you're saying here though.

> In a posix shell script (or a
> program that knows it might be run inside such a script), 0 is "true"
> and non-zero is "false."

And that's a consequence of a system wherein there is only one concept
of "success", but many concepts of "failure". Whoever devised that
system was clearly a pessimist :)

> My point here is that you have to understand
> how to work within whatever environment you're using, and that future
> programmers (and future you!)  will have to deal with your choices
> regardless of their background, biases, and preferences.

That's always the case, though.

ChrisA