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

171–180 of 339 posts

Re: The Norway Problem

#171

Post by pdkl95 »

masklinn wrote: post #35
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_...

> This is part of more general problem The more general problem basically being sentinel values (which these sorts of inferences can be treated as) in stringly-typed contexts: if everything is a string and you match some of those for special consideration, you will eventually match them in a context where that's wholly incorrect, and break something.

edit: fixed formatting problem

> sentinel values

Using in-band signaling always involves the risk of misinterpreting types.

> This is part of more general problem

DWIM ("Do What I Mean") was a terrible way to handle typos and spelling errors when Warren Teitelman tried it at Xerox PARC[1] over 50 years ago. From[2]:

>> In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another hacker there typed

    delete *$
>> to free up some disk space. (The editor there named backup files by appending $ to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren't any editor backup files, so DWIM helpfully reported

    *$ not found, assuming you meant 'delete *'
>> [...] The disgruntled victim later said he had been sorely tempted to go to Warren's office, tie Warren down in his chair in front of his workstation, and then type 'delete *$' twice.

Trying to "automagically" interpret or fix input is always a terrible idea because you cannot discover the actual intent of an author from the text they wrote. In literary criticism they call this problem "Death of the Author"[3].

[1] https://en.wikipedia.org/wiki/DWIM

[2] http://www.catb.org/jargon/html/D/DWIM.html

[3] https://tvtropes.org/pmwiki/pmwiki.php/Main/DeathOfTheAuthor

Re: The Norway Problem

#172

Post by kstenerud »

chousuke wrote: post #154
kstenerud wrote: post #123

Earlier quoted context omitted.

> 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. Unquoted strings are much nicer for humans to work with. All special keywords and object encodings are prefixed with sigils (@, &, $, #, etc), so any bare text starting with a letter is either a string or an invalid do…

If strings are always unambiquously detectable, why allow quoting them at all? Having two representations for the same data means you can't normalize a document unambiguously. I can understand having barewords seems cleaner for things like map keys, but I am not convinced that it's a worthwhile tradeoff. An important feature of RFC2119 keywords is that they're always capitalized (ie. the keyword is "MUST", not "Must"…

> If strings are always unambiquously detectable, why allow quoting them at all?

Because strings can contain whitespace and other structural characters that would confuse a parser.

> Having two representations for the same data means you can't normalize a document unambiguously.

The document will always be normalized unambiguously in binary format. The text format is a bit more lenient because humans are involved.

The idea is that the binary format is the source of truth, and is what is used in 90% of situations. The text format is only needed as a conduit for human input, or as a human readable representation of the binary data when you need to see what's going on.

> An important feature of RFC2119 keywords is that they're always capitalized (ie. the keyword is "MUST", not "Must", or "must").

Hmm good point. I'll add that.

Re: The Norway Problem

#173

Post by marcinzm »

mcv wrote: post #133

If it ignores part of the spec, I don't think "strictyaml" is the correct name here. Instead, if it interprets everything as string, perhaps "stringyaml" would have been more accurate, though I'm sure that's not as good PR. I'm reminded of the discussion we had a few days ago about environment variables; one problem there is that env variables are always strings, and sometimes you do want different types in your conf…

>If it ignores part of the spec, I don't think "strictyaml" is the correct name here.

The article didn't fully explain it but strictyaml requires a typed schema or defaults to string (or list or dict) if one is not provided. So it strictly follows the provided schema.

Re: The Norway Problem

#175

Post by unionpivo »

lixtra wrote: post #65
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’m surprised that with your experience you come to such unbalanced conclusions. Everything in engineering is about trade-offs and while your conclusions may be indisputable for the design goals of D they may wrong in other contexts. 1. If I scribble some one time code etc. the probability of having an error coming from implicit declarations is in the same order of magnitude as missing out edge cases or not getting t…

I disagree with most of what you said but I want to specifically call out:

> 3. Go on with a warning is a sane strategy in some situations.

No, if its sometimes ok, to continue, than you should not assert it.

Assert means "I assert this will always be true, and if it's not our runtime is in unknown/bad state."

If you think you can recover, or partially recover, throw/return appropriate error, and go into emergency/recovery mode.

Re: The Norway Problem

#176

Post by msiemens »

mcv wrote: post #133

If it ignores part of the spec, I don't think "strictyaml" is the correct name here. Instead, if it interprets everything as string, perhaps "stringyaml" would have been more accurate, though I'm sure that's not as good PR. I'm reminded of the discussion we had a few days ago about environment variables; one problem there is that env variables are always strings, and sometimes you do want different types in your conf…

> JSON, which is [...] unambiguous about its types

With the one exception that with floatig point values the precision is not specified in the JSON spec and thus is implementation defined[1] which may lead to its own issues and corner cases. It for sure is better than YAML's 'NO' problem, but depending on your needs JSON may have issues as well

[1]: https://stackoverflow.com/questions/35709595/why-would-you-u...

Re: The Norway Problem

#177

Post by lainga »

azernik wrote: post #24

YAML had a worse example, once. 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). So 1:11:00 would parse to the integer 4260, as in 1 hour and 11 minutes equals 4260 seconds. Now try plugging MAC addresses into that parser. The most annoying part is that the MAC addresses would only be mis-parsed if there were no hex digits in the str…

We had a Grafana dashboard where one of the columns was a short Git hash. One day, a commit got the hash `89e2520`, which Grafana's frontend helpfully decided to display as "+infinity". Presumably it was parsing 89E+2520.

Re: The Norway Problem

#178

Post by lokedhs »

lunfard00 wrote: post #136
masklinn wrote: post #80

Earlier quoted context omitted.

> 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…

There is a lot of elitism around bash, like the "Arch btw" thing but far worse because a lot of important things depends on it. Powershell has been working on linux for quite a while now and doesnt seem get any attention even when it has a nice IDE support and copy the good things about bash.

It doesn't copy all the good things about the Unix shell though.

The reason people are comfortable with the POSIX shell is because you use the same syntax for typing commands manually as you do for scripts. But, you're going to have a hard time finding people who prefers writing:

    Remove-Item some/directory -recursive
Rather than

    rm -fr some/directory
People who write shellscripts are often not seeing themselves writing a "program". They are just automating things they would do manually. Going to an IDE in this case is not something you'd consider.

I happen to be very aware of all the pitfalls in POSIX shell, and it's rare that I see a shellscript where I cannot immediately point out multiple potential problems, and I definitely agree that most scripts should probably be written in a language that doesn't contain so many guns aimed at the user's feet. I'm just pointing out a likely reason why people are not adopting powershell in the huge numbers that Microsoft may have hoped for.

Re: The Norway Problem

#179

Post by logicchains »

coopierez wrote: post #122
asiachick wrote: post #115

Earlier quoted context omitted.

What do think of implicit member access (C++, Java, C#) vs explicit (python, javascript)? Is there a concrete argument one way or the other? I feel like I prefer explicit self.member = value this.member = value vs implicit member = value But clearly C++/Java/C# people are happy with implicit ... though many of them try to make it explicit by using a naming convention.

That was my single biggest pet-peeve of C++. A variable appears in the middle of a member function? Good luck figuring out what owns it. Is it local? Owned by the class? The super-class? (And in that case - which one?) The added mental load of tracking variables' sources builds up.

FWIF, most C++ style guards recommend writing member variables like mVariableName or variable_name_ so they're easy to distinguish from local variables, and modern C++ doesn't generally make much use of inheritance so there's usually only one class it could belong to.

Re: The Norway Problem

#180

Post by wnoise »

pdkl95 wrote: post #171
masklinn wrote: post #35

Earlier quoted context omitted.

> This is part of more general problem The more general problem basically being sentinel values (which these sorts of inferences can be treated as) in stringly-typed contexts: if everything is a string and you match some of those for special consideration, you will eventually match them in a context where that's wholly incorrect, and break something.

edit: fixed formatting problem > sentinel values Using in-band signaling always involves the risk of misinterpreting types. > This is part of more general problem DWIM ("Do What I Mean") was a terrible way to handle typos and spelling errors when Warren Teitelman tried it at Xerox PARC[1] over 50 years ago. From[2]: >> In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PAR…

Eh. "Death of the Author" is a reaction to the text not being dispositive as to what the author meant. It's deciding you don't care what the author meant, no longer considering it a problem that the text doesn't reveal that. Instead the text means whatever you can argue it means.

Which can be a fun game, but is ultimately pointless.

Post reply on HN