Programming

This is often done for backward compatibility, as stdbool.h which provides true and false wasn't standard before C99 and even though that's more than 25 years ago now a lot of old habits die hard.

My boss insisted, before I arrived at the company, that everything in the database be coded so that 1 = Yes and 2 = No, because that's the way he likes to think of it. It causes us daily pain.

My brain is so used to seeing political content that I read "why do liberals define their own true and false" and was already like "what kind of shit take am I going to have fun reading today"

I work with young people starting out in IT, so I'm used to getting screenshots, and I'm so used to screenshots made with a phone instead of just capturing the screen, that I've stopped complaining... But come on! At least evaluate the result of the first picture and maybe do another if it's illegible.

It's because the Booleans sometimes are flipped in display-server technology from the 1980s, particularly anything with X11 lineage, and C didn't have Boolean values back then. More generally, sometimes it's useful to have truthhood be encoded low or 0, as in common Forths or many lower-level electrical-engineering protocols. The practice died off as popular languages started to have native Boolean values; today, about three quarters of new developers learn Python or ECMAScript as their first language, and FFI bindings are designed to paper over such low-level details. You'll also sometimes see newer C/C++ libraries depending on newer standards which add native Booleans.

As a fellow vim user with small hands, here are some tricks. The verb gU will uppercase letters but not underscores or hyphens, so sentences like gUiw can be used to uppercase an entire constant. The immediate action ~ which switches cases can be turned into a verb by :set tildeop, after which it can be used in a similar way to gU. If constants are all namespaced with a prefix followed by something unique like an underscore, then the prefix can be left out of new sections of code and added back in with a macro or a :%s replacement.

GLFW is a C library, not a C++ one, and an old one at that, and so the reason is that a long time ago, there was no bool in C. Every library would make their own true and false bc it's handy to have.

Nowadays, the type _Bool has been added to C, and C++ has built-in bool, but you can still see the legacy of no boolean in C as to use the type name "bool" as well as the key words "true" and "false" for 1 and 0, you have to include "stdbool.h," as well as in custom types in these old GL-adjacent libraries.

I love the description as well. "One." "Zero."

Some languages define True as -1, which is NOT False...

It’s for the extra helpful documentation. You see, in this fantastic example, after the author set GLFW_TRUE to 1, he explained the deep and profound meaning of the value. This exemplifies that the number 1 can also be written as a word: “One”! Some people might be able to figure this out, but the author clearly went above and beyond to make the code accessible to the open source community, encouraging contributions from anyone who’s considering improving the code. Furthermore, this follows the long held tradition of man pages - explaining the nuance of the code, in preparation for telling others to RTFM when they arrogantly ask a question.

I found the comments/answers about backwards compatibility of not defined booleans and negative true interesting and plausible.

What I first thought of was that TRUE and FALSE can be redefined, so it serves as ensurance that within the library consistent values are being used no matter what other libs and callers do with their typing and definitions.

Probably readability. Correct typing maybe too. Also better error checking.

i just like namespacing my variables anyway so there's no chance of any conflicts and so you can easily change something one place instead of everywhere