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

71–80 of 339 posts

Re: The Norway Problem

#71

Post by Aeolun »

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…

> never edit YAML by hand and always use a serialiser

I don’t follow this. If yaml is your config format, and you are not editing it by hand, what are you editing?

Re: The Norway Problem

#72

Post by dragonwriter »

its weird that this is a 2019 article misrepresenting behavior in the YAML 1.1 spec (2005) most of which reverted in the YAML 1.2 spec (2009) as being part of a nonexistent YAML 2.0 spec and justifying a library that purports to handle “YAML” ignoring the spec.

Re: The Norway Problem

#73

Post by sfvisser »

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.

Re: The Norway Problem

#74

Post by atleta »

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 very point of yaml is that it is easy to edit by hand. If you use an, I suppose, GUI editor then you don't need yaml. You could use any strictly typed serialization format. (Self describing or with a schema.)

Re: The Norway Problem

#75

Post by jansan »

Norway is one of the luckiest countries in the world. They have a vast amount of resources, can produce their electrical energy entirely from hydropower, have a great democracy, a government they can trust, a beautiful landscape and great people.

I must say that I feel a little bit of relief to see that they have problems that nobody else has, besides insanely expensive alcohol that is only sold in "wine monopoly" stores that are more heavily guarded than banks.

Re: The Norway Problem

#76

Post by tremon »

richthegeek wrote: post #64
WalterBright wrote: post #48

Earlier quoted context omitted.

Good language design involves deliberately adding redundancy which acts like a parity bit in that errors are more likely to be detected.

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.

Re: The Norway Problem

#77

Post by atleta »

WalterBright wrote: post #47

> The most tragic aspect of this bug, howevere, is that it is intended behavior according to the YAML 2.0 specification. This is one of those great ideas that sadly one needs experience to realize are really bad ideas. Every new generation of programmers has to relearn it. Other bad ideas that resurface constantly: 1. implicit declaration of variables 2. don't really need a ; as a statement terminator 3. assert shoul…

I agree with the general observation, but the need for ";" ? Quite a few languages (over a few generations) have been doing fine without the semicolon. Just to mention two: python and haskell. (Yes, python has the semicolon but you'll only ever use it to put multiple statements on a single line.)

Re: The Norway Problem

#78

Post by dragonwriter »

sdfhbdf wrote: post #28

What I am most baffled by with Yaml is the fact that it’s a superset of JSON. Whenever an input accepts YAML you can actually pass in JSON there and it’ll be valid It really surprised me when I found out and I use JSON Whenever possible since then since it’s much stricter https://en.m.wikipedia.org/wiki/JSON#YAML

> Whenever an input accepts YAML you can actually pass in JSON there and it’ll be valid

Strictly speaking, this is only true of YAML 1.2, not YAML 1.0-1.1 (the article here addresses YAML 1.1 behavior, the headline example od which was removed ib YAML 1.2 twelve years ago), though it calla YAML 1.1 “YAML 2.0”, which doesn’t actually exists.

Of course, there are lots of features, like custom types, that JSON doesn’t support, but you can still use YAML’s JSON-style syntax instead of actual JSON, for them.

Re: The Norway Problem

#79

Post by Safety1stClyde »

mattmanser wrote: post #45
paxys wrote: post #36

I will never understand why YAML didn't just require quoted strings. Did the creator not anticipate how many problems the ambiguity would cause?

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 any JSON from APIs which they reject.

> Just like browsers have huge hacks in them to handle misformed HTML.

Web browsers do deal with a variety of things, not so much JSON parsers in my experience.

Re: The Norway Problem

#80

Post by masklinn »

lunfard00 wrote: post #32
eitland wrote: post #13

There exists a couple of mainstream languages that are full of these sorts of interesting behavior, one of them is supposedly cool and productive and the other is supposedly ugly and evil.

and yet I don't see anyone complain about bash which is arguably far worse than those 2. When things get hard on bash, you will start to see python scripts on CI and whole thing is complete unreadable mess

> I don't see anyone complain about bash

You're not looking really hard then, but really

> When things get hard on bash, you will start to see python scripts

That's kinda the thing innit? Unless the system specifically only allows shell scripts (something I don't think I've ever encountered though I'm sure it exists) it's quite easy to just use something else when bash sucks, so while people will absolutely complain about it they also have an escape: don't use bash.

When a piece of software uses YAML for its configuration though, you don't really have such an option.

Furthermore, bash being a relatively old technology people know to avoid it, or what the most common pitfalls are. Though they'll still fall into these pitfalls regularly.

Post reply on HN