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

151–160 of 339 posts

Re: The Norway Problem

#151

Post by sokoloff »

JoeAltmaier wrote: post #148
sokoloff wrote: post #147

Earlier quoted context omitted.

It doesn’t compare them, it just counts down. If I enter 1-3-0-start, I get 90 seconds of cooking. If I enter 9-9-start, I get 99 seconds of cooking, so in that sense, 99 > 130. If I want about 90 seconds, I’ll use 88 as it’s faster to enter (fewer finger movements).

I've done the same thing for decades! Soul mates?

You might like this one as well.

Load soap into the dishwasher after emptying rather than after loading. If the soap dispenser is closed, the dishes are dirty.

Re: The Norway Problem

#152

Post by dangoor »

Cue also solves this problem. The "no" example is right on the front page: https://cuelang.org

I used it for configuration of a Go program recently and found it pleasant to work with. I hope the language is declared stable soon, because it's a good model.

Re: The Norway Problem

#153

Post by alpaca128 »

_kdhr wrote: post #44
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.

That’s a shrewd observation. Static types help with this somewhat. E.g. in Inflex, if I import some CSV and the string “00.10” as 0.1, then later when you try to do work on it like x == “00.10” You’ll get a type error that x is a decimal and the string literal is a string. So then you know you have to reimport it in the right way. So the type system told you that an assumption was violated. This won’t always happen,…

> E.g. sort by this field will happily do a decimal sort instead of the string 00.10.

So that system is not consistent with type checking? How is this not considered a bug?

Re: The Norway Problem

#154

Post by chousuke »

kstenerud wrote: post #123
chousuke wrote: post #106

Earlier quoted context omitted.

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.

> 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", or "must"). This makes requirements and recommendations stand out amid explanatory text, improving legibility. For example, RFC2119 itself uses MUST and must with different meanings.

Re: The Norway Problem

#156

Post by jgalt212 »

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

and cusips, which are strings, get converted to scientific notation.

https://social.msdn.microsoft.com/Forums/vstudio/en-US/92e0a...

Re: The Norway Problem

#157

Post by lelanthran »

nightcracker wrote: post #139
lelanthran wrote: post #132

Earlier quoted context omitted.

> 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.) But then it's inconsistent and has unnecessary complexity because now there's one (or more) exceptions to the rules to r…

Have you ever used Python? If you did you really wouldn't be saying this. There isn't an exception. The semicolon is used to put multiple statements on a single line. That's it's only use, and that's the only time it's 'needed' - no exceptions.

> Have you ever used Python? If you did you really wouldn't be saying this. There isn't an exception.

For the ';', perhaps not. For the token that is used to terminate (or separate) statements? Yes, the ';' is an exception to the general rule of how to terminate statements.

The semicolon also works on some sort of statements and not others, throwing errors only at runtime.

It's easier to remember one rule than many.

Re: The Norway Problem

#158

Post by lolinder »

This comment was buried in a thread, but I'm bringing it out because it's very relevant to the conversation:

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

> the article refers to YAML 2.O, a nonexistent spec, and to PyYAML, a real parser which supports only YAML 1.1.

> Both the unquoted-YES/NO-as-boolean and sexagesimal literals were removed in YAML 1.2.

Re: The Norway Problem

#159

Post by mattkrause »

afturkrull wrote: post #107
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 interf…

The analysis itself isn’t (usually) happening in Excel.

A lot of tools operate on CSV files. People use Excel to peek at the results or prepare input for other tools, and that’s how the date coercion slips in.

Sometimes, people do use it to collate the results of small manual experiments, where a database might be overkill. Even so, the data is usually analyzed elsewhere (R, graphPad, etc).

Re: The Norway Problem

#160

Post by bilalq »

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

I don't understand why those support agents for Microsoft just threw their hands up in the air and asked customers to go through some special process for reporting the bug in Excel. Why are they not empowered/able to report the issue on behalf of customers? It's so clearly a bug in Excel that even they are able to reproduce with 100% reliability.
Post reply on HN