Justin du Coeur

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...

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...

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...

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.

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.

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

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

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"

(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.

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