bool and int

[2QdxY4RzWzUUiLuE at potatochowder.com]

On 2023-01-25 at 12:14:50 +1100,
Chris Angelico <rosuav at gmail.com> wrote:

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

> > The usual complaint is that some people write FORTRAN no matter what
> > language they're actually using.  Are you writing Python in C#?  ;-)

> But the way I have to write it in C# is a messed-up version of C:

There's your problem:  C# isn't C, it's Java.  Java looks like C, too,
but it isn't C, either.

> So the problem isn't that I'm trying to write Python in C#, but that
> I'm trying to write code that would work on pretty much *any other
> C-family language*, but doesn't work on C#. I could use those
> techniques in plenty of C-derived and C-inspired languages, but nooooo
> not in C#, despite looking very much C-inspired. Unfortunately the
> truth is that C# is not *actually* C-inspired; it's really Microsoft
> Java, so it has all the stupidities of Java:

There.  Even ChrisA agrees with me.  ;-)

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.

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.

[0] I remember meetings where the agenda was to allocate memory (yes, at
design time) for a particular value, and the answer was along the lines
of "you can have these five bits, and this would have taken a lot less
time had you told us sooner that you needed that value to persist across
input messages."

> But this is hardly a Python-versus-C# thing; it's Java versus most of
> the rest of the world, and C# feigns to be part of the C style while
> retaining the limitations of Java.

IMO, the problem started when Java tried to be too much like C to
attract (or should I say "trap"?) C developers.

> (My apologies if the Java entries look synthetic. It's because they
> are, and that's a consequence of me not having ANY reason to write
> Java code in, like, ever. In fact, I had to go and install a JDK just
> to confirm that Java really did have these limitations.)

They used Java at my last job (as in, the last job I had before I
retired), and it was absolutely awful, for any number of reasons, the
gymnastics (on many levels) required to support "primitive types" being
one of them.