Yes/No or True/False?

[jducoeur]

Way back in the early days of Querki, I was figuring out what the major Property Types were going to be.  Figuring out the list was easy; figuring out what to call them was another matter, since I'm trying to avoid techie jargon in the basic parts of Querki.  So instead of "Markup", it's simply "Text", and "Integer" is "Whole Number".  (Yes, Integer is a perfectly good math word, but most people have long since forgotten their grade school math.)

And then there's the jargony-est of them all, Boolean.  It's one of the first jargon words a programmer learns, and an incredibly useful one, but it's basically a techie shibboleth.  No way was I going to use it in Querki.  After thinking about it for a while, I gave up, called a spade a spade, and named the type YesNo.

But three years on, I find that I'm reconsidering that.  Calling the values in the database "Yes" or "No" doesn't feel quite right most of the time.  You need the concept, but I'm not sure of that terminology.

So I'm looking for opinions.  What term do *you* think would be clearest for this concept, and what do you think would be clearest for the typical user -- someone moderately smart and educated, but explicitly non-technical?  Comments welcome: naming is, as ever, the hardest part of programming...
[Poll #2030349][Poll #2030349]

Comments

[etherial.livejournal.com]

I'd call the values "True" and "False" and the variable type "Truthiness".

[jducoeur]

Heh. I like it at a gut level, but in a post-Colbert Report world I think the connotations of "Truthiness" may not be quite right...

[goldsquare.livejournal.com]

I'm not sure.

We use boolean-concepts all the time (Right/Left, Yes/No, True/False, Either/Or, OneOrTheOther, ThisOrThat).

They have minor distinctions for one of two exclusive choices.

In that sense, I presume Querki has a type for "one from a sequence of choices", isn't this just the minimalist case for choice?

Or are you trying to recreate Boolean logic and algebra without the overhead of teaching math?

[jducoeur]

In that sense, I presume Querki has a type for "one from a sequence of choices", isn't this just the minimalist case for choice?

Conceptually, sure. (In practice, it is currently much too much work to define a Multiple Choice, which interferes with that being a first-class concept from a UX POV. This is increasingly high-priority; I may well add the wizard to address it in the next week. It's currently a nice object lesson in UX: the concept is currently functional, but not usable.)

But in my experience so far, the True/False dichotomy is much more common in a typical Querki Space, and in practice the implementation is wildly different from Multiple Choice. Most importantly, the YesNo type is used all over the functions, for the same reasons that it is in any functional programming language.

So while I agree that they're similar from a group-theoretic standpoint, I don't think the similarity is very helpful for this purpose. I *need* a name for this particular concept.

Your last question is roughly on-the-mark. I'm trying to avoid needing to teach *much* Boolean logic -- but the simple application of it is too central to avoid. That core concept is required so that we can talk about elementary functions like "if". Indeed, it was while I was adding the new function-Signature mechanism that I began to realize that much of the documentation currently reads somewhat unnaturally, because "Yes/No" feels a bit wrong semantically...

[goldsquare.livejournal.com]

So, I think you are cleft on a real problem.

If the name is too much like English or an English concept, it may read funny. Because, epistemologically as I said, the choice between two things is sometimes truth value, sometimes Have/Haven't, and so forth.

You may want to create a non-English term that represents the binary duality, without picking a term that implies a specific part of speech equivalence. "2Choice" or "AlternativeChoice" or something - a new noun that has a meaning you can use. The noun can hint at duality, but then your writing will use it as a noun, not as a human part-of-speech.

I can't think of a normal human word that means BinaryChoiceBetweenArbitraryChoices.

[jducoeur]

That's fair, and you may well be right -- the universality of the term "Boolean" in the software world suggests so. Indeed, that's more or less why I wound up with "YesNo" in the first place, and it wouldn't surprise me if I simply decide to change that to "TrueFalse", to slightly better match the usage. But it's going to be enough of a nuisance to make the change (since the type is pretty central), that I'm pausing to think about that and see if anybody's got cleverer ideas...

[be-well-lowell.livejournal.com]

Restating the problem: One always can present a binary choice as a yes/no or true/false option, but it can get awkward linguistically. Trying to look at that as an English speaker rather than a computer person, I'm thinking that goldsquare has the right idea, but maybe an easier implementation would be to keep a yes/no choice but suggest that some two-option choices can be best implemented through multiple choice, specifically because it already has the concept of detailing the options.

I get that this is a problem at the moment because multiple choice isn't actually available, but you have to fix that anyway.

[dsrtao]

uhhuh/uhuh

[metahacker.livejournal.com]

One of the problems is that, while programmers are used to sliding up and down the scale of abstraction, most other folks aren't. So while it makes sense implementationally to have a single type to encode a two-value thing, for users it might make sense to have a bunch of them--yes/no, true/false, left/right, up/down, enabled/disabled, and so forth.

This could be a labeling problem, but possibly not. Some folks simply won't think to grab the "2-choice" type and slap, say, "active/inactive" into the labels.

I like "yes/no" for its non-technical-ness. But it might trip up folks who are trying to encode something where "yes" is confusing.

[jducoeur]

for users it might make sense to have a bunch of them--yes/no, true/false, left/right, up/down, enabled/disabled, and so forth

Hmm. Interesting point, and in principle I suspect you're right. In practice, though, it *is* actually a single type, and kinda has to show up in the UI that way in some places. (Eg, when creating a Property of this type, what do we call it?)

And that being the case, I worry that being inconsistent in the terminology may be pointlessly confusing. Indeed, that's the *precise* cause of me asking this question: I found that I was having difficulty being consistent typing "Yes" and "No" in the documentation, and keep reflexively using "True" and "False" because they sound more correct to me. I suspect that inconsistency is Bad, so I want to make a decision I can stick to.

Some folks simply won't think to grab the "2-choice" type and slap, say, "active/inactive" into the labels.

True, and I probably don't care passionately if so -- using Multiple Choice should generally work, if with a bit more effort. But this "2-choice" is going to be somewhat emphasized in the UI -- I believe it's going to be one of the small number of "basic" types, so it'll be front-and-center, precisely because it's easier to use.

(One of the things I'd like to chat with you about is my hypothesis of having a somewhat multi-level UI, depending on the user's self-declared comfort level, with the Advanced features relatively hidden away unless the user explicitly wants to deal with them. In theory, that makes some sense, but I'm not sure I know all the traps to watch for...)

[laurion]

I like the idea of the 'This or That' type. You can have this, or you can have that. But it's at least as terrible an abstraction as Boolean.

[jducoeur]

I should be clear: I don't mind the *abstraction* of Boolean -- I think it's somewhere between useful and strictly necessary. It's the *word* that I'm trying to avoid, because it's totally opaque to non-programmers. (So far, I'm leaning towards the crude but clear "TrueOrFalse", but continuing to think on it...)

[mindways]

I'm positive "Boolean" is the wrong terminology to use.

I strongly suspect that "TrueOrFalse" is better than "TrueFalse", and that either is better than "YesNo".

[jducoeur]

Mmm -- good point. I might well go with that...

[hudebnik.livejournal.com]

Most people who attended a U.S. school are familiar with the notion of "true/false questions", so if you called it "TrueOrFalse" people would almost certainly understand what you meant (although they might have negative associations with test-taking, or conclude that as with a true/false question, you can flip a coin for the answer and you're 50% likely to be right). "TrueFalse" sounds oxymoronic to me.

For other two-way choices like "LeftOrRight", I wouldn't try to force them to use the same type: that's a programmerese data-representation decision. Instead, work on that "choices" UI :-)

BTW, does "choices" mean basically an enum of finitely many discrete values, or does it cover polymorphism of distinct types too? For example, could I define List as "choice between Empty and (First Object together with Rest List)"? [Made-up syntax; I haven't done any Querki.]

I worked in a programming language (long long ago, in a galaxy far far away) in which "whether" was the identity function but enforced that its argument type was Boolean. It made a lot of code more readable: "set Overtime to whether hours > 40"

[jducoeur]

(Note: I'm getting into some of the technical details below. Much of it's not terribly obvious to the beginner, but is very relevant when you get into Advanced Querki, and start doing really programmer-y stuff with it.)

BTW, does "choices" mean basically an enum of finitely many discrete values, or does it cover polymorphism of distinct types too? For example, could I define List as "choice between Empty and (First Object together with Rest List)"?

The Multiple Choice Type means precisely the former -- indeed, it was originally called Enumeration, until tpau suggested Multiple Choice. (The concept is really a design pattern under the hood: it's a Link that is constrained to values of a particular Model whose values represent the enumeration. It's quite powerful, roughly cognate to Java's enumerations. But I'm finally getting sufficiently exasperated with it to wrap it up in a pseudo-Type + UI that does all the work behind the scenes.)

Polymorphism's a complicated question in Querki. Mind, the type system is vaguely Java-ish: there are "primitive" Types like YesNo and Whole Number, and then there are Link and Tag, which are basically pointers. Those pointers are potentially kind of polymorphic: you can constrain a Link to a particular Model (~class), including sub-Models, but you can also leave it unconstrained. And regardless, Querki is *mostly* duck-typed internally -- even once I evolve the QL language to be relatively strongly typed, it's going to be mainly structural typing rather than nominal, with (if I can pull it off) validation focused on structural type inference.

Also, note that Type is specifically separated from Collection. This is one of Querki's quirkiest concepts, and one of the biggest conceptual risks. Basically, instead of values being normally single-valued (as in every programming language I know), and doing fancy Type stuff to build more complex ones, *every* Property value in Querki has a concept of "how many" -- roughly speaking, you *only* speak in terms of monads. That is, you have to declare upfront whether this Property holds ExactlyOne, Optional (zero or one), List or Set. ExactlyOne is the default, but internally Querki mainly thinks in terms of Lists.

So while it would be possible to build your definition (using Model Types, which are how you build arbitrary data structures), List is built-in and first-class. I keep expecting to need to add more Collections, but so far I've only really needed those four. Indeed, I keep wavering on whether to remove Set -- so far, I've only ever found the distinction between List and Set to matter for Links, and even there I mainly care in terms of the UI.

[hudebnik.livejournal.com]

Yes, I was pretty sure you must already have a "list" type or equivalent; that was just an example of the kind of data definition one might want to be able to do with polymorphism.

Speaking of that programming language long long ago, in a galaxy far far away, I think its word for Boolean was "flag".

[jducoeur]

Hmm. "Flag" isn't bad -- so far, I think I like that and the call-it-a-spade TrueOrFalse best. Ponder...

[mneme]

Assertion.

Binary (most people who don't understand "boolean" still understand that a "binary" thing only has two values).

[hudebnik.livejournal.com]

Ooh, are we playing the alphabet game? Me too!

Assertion

Binary (if not Boolean)

Choice

Decision

Either

Flag

Umm... I'm stuck on G....

[tpau]

see, i would call it a Boolean, and in the exposed user thing show examples. i say this because clearly you have 20 replies here, and they are mostly all saying various things.

alternately, flag or on/off may work BUT... i would call it Boolean. because honestly it is what it is, and most users actually know the word these days. the helpy texgt would help the 20%

[jducoeur]

most users actually know the word these days

Really? I'm intrigued. That's unintuitive to me -- I'm having trouble remembering any time I've seen it in non-technical usage -- but I'd certainly be happy to find that this is true. I wonder how we could test this. (My LJ, and even my FB, are obviously wildly unrepresentative...)

[tpau]

hmm, not sure how to test it honestly. my experience is purely anecdotal