The Norway Problem • Hacker News Board

Re: The Norway Problem

#81

Post by dragonwriter » Sat, Apr 03, 2021, 10:35 AM UTC

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 insufficiently analysed by the article author

The article author also misidentifies the version of the YAML spec (calling it 2.0, which doesn’t exist; the behavior is from YAML 1.1, and this class of problems motivated a bunch of changes in YAML 1.2, which has been out since 2009.)

But the article author isn’t trying to analyze the problem, he’s trying to rationalize why what is notionally a YAML-processing library just ignores the spec.

Re: The Norway Problem

#82

Post by masklinn » Sat, Apr 03, 2021, 10:38 AM UTC

trhway wrote: post #34

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.

XML with a convenient UI tools to edit should have fit the bill. Yet, for whatever reason a convenient UI tool would never happen to be there when needed, and thus scared and tired of manual editing of XML the world have embraced YAML.

> XML with a convenient UI tools to edit should have fit the bill.

"You need this special tool to work" immediately and instantly rules out "easy to edit". Or makes the debate irrelevant: every format is easy to edit if you have "a convenient UI" to do it for you.

Re: The Norway Problem

#83

Post by dragonwriter » Sat, Apr 03, 2021, 10:41 AM UTC

Hendrikto wrote: post #58

> The real fix requires explicitly disregaring the spec Or… just quote your strings.

Or, “use an appropriate schema”. Or, for several of the specific problems identified in the source article, use YAML 1.2 (2009) instead of YAML 1.1 (2005), which the article misidentifies as “YAML 2.0” and acts as if it is the current spec.

Re: The Norway Problem

#84

Post by jasode » Sat, Apr 03, 2021, 10:41 AM UTC

helsinkiandrew wrote: post #68

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 I can just about understand that "No" might cause a problem, but “Membrane Associated Ring-CH-Type Finger 1" being converted to MAR-1 defeats me.

>, but “Membrane Associated Ring-CH-Type Finger 1" being converted to MAR-1 defeats me.

No, that's not what's happening. To clarify...

If you type a 41 characters long string of "Membrane Associated Ring-CH-Type Finger 1" into a cell -- Excel will not convert that to a date of MAR-1.

On the other hand, it's if you type an 6-char abbreviation of "MARCH1" that looks like a realistic date -- Excel converts it to MAR-1.

Re: The Norway Problem

#85

Post by makkesk8 » Sat, Apr 03, 2021, 10:47 AM UTC

We too had this problem, we solved it using the 3 letter country code instead.

Re: The Norway Problem

#86

Post by [deleted] » Sat, Apr 03, 2021, 10:49 AM UTC

dkersten wrote: post #40

yellowapple wrote: post #12

This is exactly why configuration/serialization formats should make as few assumptions about value types as possible. Once parsing's done, everything should be a string (or possibly a symbol/atom, if the program ingesting such a file supports those), and it should be up to the application to convert values to the types it expects. This is Tcl's approach, and it's about as sensible as it gets. ...which is why it pains…

It’s reasons like this that I want my configuration languages to be explicit and unambiguous. This is why I use JSON or if I want a human friendly format, TOML. Strings are always “quoted” and numbers are always unquoted 1.2, it can never accidentally parse one as the other. The convenience of omitting quotes is just not worth the potential for ambiguity or edge cases to me.

[deleted]

Re: The Norway Problem

#87

Post by throwaway4good » Sat, Apr 03, 2021, 10:50 AM UTC

Just use json.

Re: The Norway Problem

#88

Post by ancarda » Sat, Apr 03, 2021, 10:51 AM UTC

You can catch this with yamllint (https://github.com/adrienverge/yamllint):

    % cat countries.yml 
    ---
    countries:
      - US
      - GB
      - NO
      - FR

    % yamllint countries.yml 
    countries.yml
      5:4       warning  truthy value should be one of [false, true]  (truthy)

Re: The Norway Problem

#89

Post by thaumasiotes » Sat, Apr 03, 2021, 10:51 AM UTC

tremon wrote: post #76

richthegeek wrote: post #64

Earlier quoted context omitted.

That's an interesting statement to apply to natural languages. Consider this headline in English: "Man attacks boy with knife". This can be read two ways, either the man is using a knife to attack the boy, or the boy had the knife and thus was being attacked. The same sentence in Polish would make use of either genitive or instrumental case to disambiguate (although barely). However, a naive translation would only di…

does the inclusion/requirement of parity features reduce the expressivity of the language? This was a real eye-opener for me when learning Latin in school: stylistic expressions such as meter, juxtaposition, symmetry are so much easier to include when the meaning of a sentence doesn't depend on word order.

> stylistic expressions such as meter, juxtaposition, symmetry are so much easier to include when the meaning of a sentence doesn't depend on word order.

Eh.... some things are easy and some things are hard in any language. The specifics differ, and so do the details of what kinds of things you're looking for in poetry. Traditional Germanic verse focuses on alliteration. Modern English verse focuses on rhyme. Latin verse focuses on neither. [1]

English divides poetically strong syllables from poetically weak syllables according to stress. It also has mechanisms for promoting weak syllables to strong ones if they're surrounded by other weak syllables.

In contrast, Latin divides strong syllables from weak syllables by length. Stress is irrelevant. But while stress can be changed easily, you're much more restricted when it comes to syllable length -- and so Publius Ovidius Naso is invariably referred to by cognomen in verse, because it isn't possible to fit his nomen, Ovidius, into a Latin metrical scheme. That's not a problem English has.

[1] I am aware of one exceptional Latin verse:

> O Tite, tute, Tati, tibi tanta, tyranne, tulisti.

Re: The Norway Problem

#90

Post by eitland » Sat, Apr 03, 2021, 10:53 AM UTC

pansa2 wrote: post #27

speedgoose wrote: post #26

Earlier quoted context omitted.

Python vs PHP also.

> full of these sorts of interesting behavior I don’t think that applies to Python - it’s quite strongly (although not statically) typed. I agree that it does apply to JavaScript and PHP.

Javascript and PHP is correct.