bool and int

[2QdxY4RzWzUUiLuE at potatochowder.com]

On 2023-01-25 at 23:11:37 +1100,
Chris Angelico <rosuav at gmail.com> wrote:

> On Wed, 25 Jan 2023 at 22:55, <2QdxY4RzWzUUiLuE at potatochowder.com> wrote:

> > So, I think what you're trying to say is that you prefer the razor sharp
> > quality of truthiness to the zen of explicit being better than implicit.
> 
> Not sure what you mean here. If you want to bring this back to the Zen
> of Python, I would reference "practicality beats purity". We can do
> arithmetic on integers and floats without having to explicitly cast
> one to the other, because there's really no point in distinguishing
> them. We can do that with booleans and other types, too.

My point was that we all have our own preferences and biases, and in
this case, I think you and I lean in opposite directions, and Python is
big enough for both of us.

> > To bring this back to Python (sorry), blurring the line between booleans
> > and integers is an old machine language trick, born of the days when we
> > measured memory in bytes (and large sums of cash!) rather than gigs[0].
> > In Python3, there's no more reason to use a boolean value as integer
> > (whether to accumulate values or to test a value against zero) as there
> > is to use a string (e.g., from an HTML form) as an integer.
> 
> 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).

Maintainability, too:  as soon as there's something else to do when
AT_mode isn't AT.Idle, I'm going to rewrite the first one as the second
one anyway.  (No, I won't mess up the braces.)

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'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).  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."  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.

> C# is a pain to work with because it fails on these points of
> practicality. I'm morbidly curious as to how C# fanatics justify this
> sort of thing, given that so many languages just DTRT without needing
> to be told.

They say that Perl is practical.  ;-)