Hacker News Reader

Comment by xigoi | Hacker News Reader

I’m sad that the “fix” was to disallow “no” as a more readable alternative to “false”, rather than to disallow unquoted strings.

View on HN

It’s silly to have so many keyword synonyms as specified in that earlier regex. I’m also glad we can’t specify numeric literals as roman numerals. KISS

Honestly I’d prefer if “yes” and “no” were the only ways to spell the boolean values. They make sense in pretty much all contexts where booleans are used, whereas “true” and “false” rarely make sense.

In boolean logic true/false is ubiquitious and well known. As you can see, if one tries to be cute with it, one will get all sorts of issues. So at this point it doesnt make sense to use anything else.

The true/false terminology makes sense in boolean logic because you’re dealing with the truth of propositions. However, it does not make sense in the context of a configuration language, where there are no propositions that could be true or false.

Huh, I never considered this. we take true and false for granted everywhere but they aren't the most meaningful.

It makes sense in the context of a configuration language because virtually 100% of programmers and other technical computer users understand “true” and “false” as the canonical Boolean values, and as far as I know that has always been the case. It never would have made sense to invent different unfamiliar terms like “yes” and “no” because of some niche philosophical distinction between “Boolean logic” and “configuration” that almost nobody in the real world cares about.

“yes” and “no” are “unfamiliar terms”? What the fuck? Everyone who knows even the basics of English knows what these words mean.

They are familiar as English words, yes, but unfamiliar as terms of art for Boolean values in computing. It’d be like replacing “if” statements with “whenever” statements.

Don’t give them any ideas! They already tried to make inroads with ruby’s “unless”.

Boolean algebra with true and false was well established decades before computers were invented

Boolean algebra deals with logical propositions, not with configuration. The true/false terminology makes sense there.

The fix is to make conversion user-controllable. If you want to disallow bare scalars except for booleans and numbers or whatever, it's just a little bit of configuration away.

Why do you need an alternative spelling of false?

`logging: no` clearly says “I do not want logging”. `logging: false` is less explicit – what exactly is false?

Then it should be on/off, not yes/no.

on/off also doesn’t make sense in many contexts, for example `isRegistered: on`.

I often prefer enums over booleans for this. It seems more readable for most cases, and can be extended with new values.

This:

    isRegistered: true

could be replaced with

    accountStatus: "UNREGISTRED"

Logging: ignore/print/file

Don’t use bool at all.

This, along with number formats, could be a good argument for strings being the only primitive type in config languages.

I recently learned about NestedText: https://nestedtext.org/

While it has the YAML-like significant whitespace, it looks nice because it doesn't try to be clever.

Logging: no could also be log in norwegian. Or log only for the norwegian region. That's the thing with too many keywords and optional quoting, you can't know.

And for this reason, "logging: false" would be clearer than "logging: no" to represent "I do not want logging".

`false` could be a code for something else just as well as `no`. For example, it could mean that I only want to see logs of false information appearing in the system. The only proper solution is to require quotes around strings.

Options are either

1. Specify in the key

  loggingEnabled: false

2. Specify in the value:

  logging: disabled

Yeah, you still get the same issue that 3 is an integer, 3.3 is a float and 3.3.3 is a string.

Reply on news.ycombinator.com