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

101–110 of 339 posts

Re: The Norway Problem

#101

Post by kstenerud »

anticristi wrote: post #94
kstenerud wrote: post #52

Earlier quoted context omitted.

This is the problem space I'm targeting with https://concise-encoding.org/ * Text AND binary so that humans can edit easily, and machines can transmit energy and bandwidth efficiently. * Carefully designed spec to avoid ambiguities (and their security implications). * Strong type support so you're not using all kinds of incompatible hacks to serialize your data. * Versioned, because there's no such thing as the perfe…

Nice! I like some concepts that this format proposes, but the `@` and `|` modifier feels a bit too "loaded".

It's a compromise; there are only so many letters, numbers, and symbols available in a single keystroke on all keyboards, and I don't want there to be any ambiguity with numbers and unquoted strings (e.g. interpreting the unquoted string value true as the boolean value true).

So everything else needs some kind of initiator and/or container syntax to logically separate it from the other objects when interpreted by a human or machine.

Re: The Norway Problem

#102

Post by pdpi »

bonzini wrote: post #33
m463 wrote: post #30

Earlier quoted context omitted.

slightly related, on my microwave 99 > 100, even 61 > 100

Why does your microwave compare numbers?

Not the OP, but I have the same problem. For some reason that escapes me, pressing the “10 sec” button 7 times produces 00 70 instead of 01 10. If you then press the “1 min” button you get 01 70

Re: The Norway Problem

#103

Post by bmn__ »

sfvisser wrote: post #73
bmn__ wrote: post #69

The problem is insufficiently analysed by the article author and the commenters in this thread so far. It is very superficial. The recent thread "Can’t use iCloud with “true” as the last name" https://news.ycombinator.com/item?id=26364993 went deeper. Let me take up its relevant particulars into this thread. The article author hitchdev does not say it outright, but it is heavily implied that the YAML file was edited…

The problem is not 'someone is not correctly following the serialization rules', the problem is 'the serialization rules are quite terrible'. This is not some interesting trade-off, this problem is fixable on all axes by using non-ambiguous, non-overloaded typing rules for your config format. Even JSON and XML got this right.

> The problem is not 'someone is not correctly following the serialization rules'

Yes, yes, I pointed that out. grep "immediate cause" and "indirect root"

> the serialization rules are quite terrible

Did that need to be said explicitly? I agree FWIW. I have already made a value judgement mildly against YAML, in case that's not clear. It's only mild because the problem can be worked around. I think this approach is more practical than moving the whole world over to a completely different thing.

> problem is fixable […] non-ambiguous […] rules

Is the implication here that you say YAML is ambiguous? It's not. I don't want sloppy analysis. To be precise, the ambiguity is imagined, it does not exist on the spec or software level, only in the head of people.

Re: The Norway Problem

#105

Post by unhammer »

anticristi wrote: post #29
Arnavion wrote: post #20

Earlier quoted context omitted.

They all have their downsides. JSON: - no comments, unless you fake them with fake properties, unless your configuration has a schema that doesn't allow extra fake properties - no trailing commas; makes editing more annoying - no raw strings YAML: - the automatic type coercion - the many ways to encode strings ( https://yaml-multiline.info/ ) - the roulette wheel of whether this particular parser is anal about two-sp…

This makes me sad. It's 2021 and we still haven't figure out how to serialize configuration in a format that is easy-to-edit and predictable.

https://dhall-lang.org/ ?

Re: The Norway Problem

#106

Post by chousuke »

kstenerud wrote: post #52
anticristi wrote: post #29

Earlier quoted context omitted.

This makes me sad. It's 2021 and we still haven't figure out how to serialize configuration in a format that is easy-to-edit and predictable.

This is the problem space I'm targeting with https://concise-encoding.org/ * Text AND binary so that humans can edit easily, and machines can transmit energy and bandwidth efficiently. * Carefully designed spec to avoid ambiguities (and their security implications). * Strong type support so you're not using all kinds of incompatible hacks to serialize your data. * Versioned, because there's no such thing as the perfe…

I'm skimming through the human readable spec, and it seems decent, but I noticed the spec allows unquoted strings. What's the reasoning for this? In my experience unquoted strings cause nothing but trouble, and are confusing to humans who may interpret them as keywords.

Any reason for not using RFC2119 keywords in the spec? Using them should make the spec easier to read.

Re: The Norway Problem

#107

Post by afturkrull »

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

> they had to rename a gene to stop excel auto-completing it into a date.

No one in their right mind uses a spreadsheet for data analysis. Good for working out your ideas but not in a production environment. I figure excel was chosen as this the utility the scientists were most familiar with.

The proper tool for the job would be a database. I recall reading about a utility, a highly customized database with an interface that looks just like a spreadsheet.

Re: The Norway Problem

#108

Post by dan-robertson »

Other reasons to not want types happening during parse time:

- “modified” numbers, e.g. $50, 35%, 1.2345568896347853246863477

- Dates. If your language tries to convert a date to Unix time or Julian Day, you can have problems with time zones or distant or historical dates.

- strings vs symbols. The person writing config shouldn’t have to care about this distinction.

- Automatic deduplication for fields of objects can be a problem.

Re: The Norway Problem

#109

Post by ravanave »

Btw, the reason Haskell isn’t used more isn’t type system per se, as all types can be inferred at the compilation time. People would sometimes use this feature even to see if GHCi guesses the type correctly (by correctly I mean exactly how the user wants, technically it’s correct always) first time and save them some time writing it either with an extension or just copy&paste from the interpreter window.

When it gets hairy is that most programming languages have low entrance barrier. To write Haskell effectively you’ve got to unlearn a lot of rooted bad habits and you get to dive into the “mathematical” aspect of the language. Not only you got monads, but there’s plethora of other types you need to get comfortably onboard with and the whole branch of mathematics talking about types (you don’t need to even know that such a field as category theory exists to use it).

However, since most people just want to write X, or just want hire a dev team at price they can afford, Haskell rarely is the first choice language.

Re: The Norway Problem

#110

Post by Macha »

Safety1stClyde wrote: post #79
mattmanser wrote: post #45

Earlier quoted context omitted.

Never's a strong word, seems quite easy to understand why to me. You've got ease of use reasons, historical reasons like the mis-guided Robustness principle, etc. And these sort of things happen time and time again. And although officially JSON requires quoted strings, almost none of the parsers actually enforce that, and so you will find a huge amount of JSON out there that is not actually compliant with the officia…

> And although officially JSON requires quoted strings, almost none of the parsers actually enforce that What programming language? I'm not familiar with those parsers, the ones I know of very much do enforce quoted strings. > you will find a huge amount of JSON out there that is not actually compliant with the official spec The parsers I use all follow the current JSON RFC specification, and I've never encountered a…

I think the point is that they accept more than the spec dictates - do your JSON parsers accept e.g. the vs code config file (JSON with comments) or JSON with unquoted keys?
Post reply on HN