Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Norway Problem

hitchdev.com

Post reply on HN
Print view View original

321–330 of 339 posts

Re: The Norway Problem

#321

Post by imtringued »

azernik wrote: post #293
adwn wrote: post #92

Earlier quoted context omitted.

> For the ease of entering time units YAML 1.1 parsed any set of two digits, separated by colons, as a number in sexagesimal (base 60). This is a mind-boggling level of idiocy. Even leaving aside the MAC address problem, this conversion treats "11:15" (= 675) different from "11:15:00" (= 40500), even though those denote the same time, while treating "00:15:00" (15 minutes past midnight) and "15:00" (3 in the afternoo…

You know you've fucked up when you have to remove features from the spec (which they did in YAML 1.2).

On the other hand, you know that you did well, when a direct competitor would look exactly the same minus some undesired features.

Re: The Norway Problem

#322

Post by zomglings »

BlueTemplar wrote: post #316
zomglings wrote: post #315

Earlier quoted context omitted.

Hashes are NOT numbers in base 10 scientific notation, which is how the hash that I showed you would be interpreted by YAML. The point is that this behavior is sporadic. It doesn't apply consistently across all git hashes, which is the real problem. It is easy to be caught unawares by this behavior.

Yes, I got that, but why have you declared a hash, which is a number, though a different kind of number than a base 10 scientific notation, as a string ?

Because we were not using any numerical properties of the hash. We were not adding it to other hashes, seeing if it was greater than or less than other hashes, etc.

Literally the only thing we were doing was passing it between shell commands, helm charts, Kubernetes deployments and then back (if we needed to debug).

It sounds like you have a more attractive alternative in this case than to treat hashes as strings. Would love to hear it.

Re: The Norway Problem

#323

Post by medstrom »

sneak wrote: post #294
medstrom wrote: post #270

Earlier quoted context omitted.

Rinse until visually clean, then put in dishwasher.

This doubles the time required to do the dishes, defeating much of the purpose of the dishwasher.

Idk, to me it's not about time but effort. Rinsing is just pleasant.

Re: The Norway Problem

#324

Post by BlueTemplar »

zomglings wrote: post #322
BlueTemplar wrote: post #316

Earlier quoted context omitted.

Yes, I got that, but why have you declared a hash, which is a number, though a different kind of number than a base 10 scientific notation, as a string ?

Because we were not using any numerical properties of the hash. We were not adding it to other hashes, seeing if it was greater than or less than other hashes, etc. Literally the only thing we were doing was passing it between shell commands, helm charts, Kubernetes deployments and then back (if we needed to debug). It sounds like you have a more attractive alternative in this case than to treat hashes as strings. Wo…

In the same thread :

https://news.ycombinator.com/item?id=26679590

Concise encoding seems to have an hex-int type ?

Re: The Norway Problem

#325

Post by [deleted] »

svnpenn wrote: post #238
atombender wrote: post #228

Earlier quoted context omitted.

TOML quickly breaks down with lots of nested arrays of objects. For example: a: b: - c: 1 - d: - e: 2 - f: g: 3 Turns into this, which is unreadable: [[a.b]] c = 1 [[a.b]] [[a.b.d]] e = 2 [[a.b.d]] [a.b.d.f] g = 3 TOML also has a few restrictions, such as not supporting mixed-type arrays like [1, "hello", true], or arrays at the root of the data. JSON can represent any TOML value (as far as I know), but TOML cannot r…

Looks fine to me: [[a.b]] c = 1 d = [ { e = 2 }, { f = { g = 3 } } ]

[deleted]

Re: The Norway Problem

#326

Post by gnud »

diggan wrote: post #279
gnud wrote: post #264

Earlier quoted context omitted.

S-expressions inherits all trouble with data types from json (dates, times, booleans, integer size, number vs numeric string). You get neat ways of nesting data, but that is not enough for a robust and mistake-resilient configuration language. The problem isn't parsing in itself. The problem is having clear sematics, without devolving into full SGML DTDs (or worse still, XML schemas).

> S-expressions inherits all trouble with data types from json (dates, times, booleans, integer size, number vs numeric string). Hm, not sure that's true, S-expressions would only define the "shape" of how you're defining something, not the semantics of how you're defining something. EDN https://github.com/edn-format/edn for all purposes is S-expressions and have support for custom literals and more, to avoid "the tr…

Yes, EDN is S-expressions plus a bunch of semantic rules. Parsing EDN is quite a bit more complex than just parsing S-expressions, just because you need to support a bunch of built in types, as well as arbitrary exensions through 'tags'.

The tag system is quite brilliant though.

Re: The Norway Problem

#327

Post by dwheeler »

The YAML specification eliminated this problem in 2009, with the release of version 1.2. That spec also eliminated some other problematic problems.

The real problem is that YAML parsers in wide use have not been updated to the spec that was released TWELVE years ago.

So who's going to help the common YAML parser developers update their implementations to support version 1.2? I think that would be a big help. Maybe the Norwegian government can chip in some money & time to get them updated, that would probably quietly eliminate a number of problems.

Re: The Norway Problem

#328

Post by dwheeler »

dwheeler wrote: post #327

The YAML specification eliminated this problem in 2009, with the release of version 1.2. That spec also eliminated some other problematic problems. The real problem is that YAML parsers in wide use have not been updated to the spec that was released TWELVE years ago. So who's going to help the common YAML parser developers update their implementations to support version 1.2? I think that would be a big help. Maybe th…

I'm replying-to-myself, because I think this text from YAML 1.2 (explaining its changes) are key:

> The primary objective of this revision is to bring YAML into compliance with JSON as an official subset. YAML 1.2 is compatible with 1.1 for most practical applications - this is a minor revision. An expected source of incompatibility with prior versions of YAML, especially the syck implementation, is the change in implicit typing rules. We have removed unique implicit typing rules and have updated these rules to align them with JSON's productions. In this version of YAML, boolean values may be serialized as “true” or “false”; the empty scalar as “null”. Unquoted numeric values are a superset of JSON's numeric production. Other changes in the specification were the removal of the Unicode line breaks and production bug fixes. We also define 3 built-in implicit typing rule sets: untyped, strict JSON, and a more flexible YAML rule set that extends JSON typing."

Since "no" is not the same as false, the Norway problem disappears. It's safer to always quote single-word strings like 'this', just like you always have to quote all strings in JSON.

Re: The Norway Problem

#329

Post by nullsense »

BlueTemplar wrote: post #298
nullsense wrote: post #288

Earlier quoted context omitted.

Easiest solution is just to rename Norway.

"Renaming it to Xorway resulted in untold damages from computer bugs..." - Narrator

Norway Orway Xorway Nandway Andway

Yes, yes, I see... This could be problematic, indeed. If only there were a logical solution.

Re: The Norway Problem

#330

Post by commandlinefan »

keeperofdakeys wrote: post #25

This is part of more general problem, they had to rename a gene to stop excel auto-completing it into a date. https://www.theverge.com/2020/8/6/21355674/human-genes-renam... Edit: Apparently Excel has its own Norway Problem ... https://answers.microsoft.com/en-us/msoffice/forum/msoffice_...

There’s a really simple solution to this problem, which has been around since the 70’s: schemas.
Post reply on HN