Hacker News Reader

Comment by stouset | Hacker News Reader

The “real” issue is an untyped configuration language which tries to guess at what you actually meant by 1. They’re tripling down on this by making 1 a Boolean true but other integers be deciseconds. This is the same questionable logic behind YAML’s infamous “no” == false.

View on HN

I'd say the new addition is more of a special case of rounding than it is messing up types.

1 was also accepted as a Boolean true in this context, and it still is in other contexts.

> 1 was also accepted as a Boolean true in this context, and it still is in other contexts.

Is "was" before the change described at the end of the article, or after it?

Before the change, any positive number implied that the feature is on, because that's the only thing that makes sense.

After the change, you could say that 1 stops being treated as a number, but it's simpler to say it's still being treated as a number and is getting rounded down. The interpretation of various types is still messy, but it didn't get more messy.

In an earlier iteration the configuration value was Boolean true/false. A 1 was interpreted as true. They changed it to an integral value. This is the entire setup for the problem in the article.

Elsewhere, 1 is still allowed as a true equivalent.

But then they made it not be a boolean when they added the delay. They went the opposite direction and it caused problems. How is this a situation of "tripling down"? It seems to me like they couldn't make up their mind.

The only reason they even need this further hack is because people can reasonably assume that 1 is bool.

Now, because of this confusion, they’re special-casing 1 to actually mean 0. But other integers are still themselves. They’ve also now added logic to make "yes", "no", "true", "off“ strings be interpreted as booleans now too.

NO is the country code for Norway.

"The Norway Problem": https://hitchdev.com/strictyaml/why/implicit-typing-removed/

Reply on news.ycombinator.com