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

301–310 of 339 posts

Re: The Norway Problem

#301

Post by BlueTemplar »

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

And of course the plague that is CSV when your decimal delimiter is ,

Re: The Norway Problem

#302

Post by BlueTemplar »

dalbasal wrote: post #54
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 suppose this is a cliched thought, but the more general problem kind of emblematic of current "smart" features... and their expected successors. OOH, this is a a typically human problem. We have a system. It's partly designed, partly evolved^. It's true enough to serve well in the contexts we use it in on most days. There are bugs in places (like norway, lol) that we didn't think of initially, and haven't encounter…

"The computer won't let me" is a particularly maddening "excuse" from bureaucrats...

Re: The Norway Problem

#303

Post by BlueTemplar »

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…

And yet, we are still being taught to use an Excel (2003) spreadsheet for data analysis... (Because that's what most businesses are still using !)

Re: The Norway Problem

#304

Post by BlueTemplar »

rubyn00bie wrote: post #226
atombender wrote: post #191

The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language)…

Your list is like a graveyard of my dreams and hopes. Anything that doesn't validate the format of the underlying data is pretty much dead to me... The problem with most of these is they're useless to describe the data. Honestly, it is completely not useful to have the following to describe data: email => string name => string dob => string IMHO, it is akin to having a dictionary (like Oxford English) read like: emai…

Sounds like your issue is that UUID is NOT a string, but a 128-bit integer ?

Re: The Norway Problem

#305

Post by BlueTemplar »

fmakunbound wrote: post #289
MrPatan wrote: post #274

Earlier quoted context omitted.

Parent didn't say it was harder to use from JS. Parent said "It had to be replaced with JSON by the web developers though, so they could just “eval() it” to get their data." First of all, I was there 20 years ago. I had to deal with XML, XSLT, one kind of Java XML parsers that didn't fully do what I needed, another kind of Java XML parsers that didn't fully do what I needed. And oh boy was it a pain. I just wanted to…

> Second, JSON always had a parser in JS, so I don't know where that eval nonsense is coming from. Firstly, it sounds like XML ran over your dog or something. Sorry to hear about that. It wasn’t particularly hard to use at all, and if you’re dealing with the possibility of emojis in your JSON UUIDs in 2021, one might even say it’s easier to use. If you’re referring to JSON.parse() in “had a parser” above, then you ha…

Another issue is that due to their age, a lot of XML tools ignore the existence of Unicode (or UTF-8).

Re: The Norway Problem

#306

Post by BlueTemplar »

hansvm wrote: post #227
atombender wrote: post #191

The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language)…

> The world desperately needs a replacement for YAML. For situations like TFA you really want a configuration language that behaves exactly like you think it will, and since you don't have to interop with other organizations you don't really need a global standard. Moreover, broadly used config languages can be somewhat counterproductive to that goal. Take JSON as an example; idiomatic JSON serdes in multiple program…

> and since you don't have to interop with other organizations

Until you have to, and all hell breaks loose ?

Now, the example of codepages maybe isn't really appropriate to companies, but is still a good enough metaphor ?

Re: The Norway Problem

#307

Post by BlueTemplar »

atombender wrote: post #191

The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language)…

Besides this issue, what's wrong with YAML ?

Re: The Norway Problem

#308

Post by BlueTemplar »

lainga wrote: post #177
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.

Sounds like the core issue is that an hexadecimal number was encoded as a string ?

Re: The Norway Problem

#309

Post by BlueTemplar »

jrockway wrote: post #272
unionpivo wrote: post #205

Earlier quoted context omitted.

> Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits. Several points: 1. Most of such critical components have several different and independent implementations, with analog backup (if possible). 2. You are arguing one specific safety critical case, that 99.999% or even more programmers will never face, should somehow inform decision…

I agree with this. Nuclear reactors are a special case of systems where removing energy from the system makes it more unsafe, because it generates its own energy and without a control system it will generate so much energy that it destroys itself (and due to the nature of radiation, destroys the surrounding suburbs too). With most systems, the safest state is off. CNC machine making a weird noise? Smash that e-stop.…

Modern nuclear reactors are designed and built with the expectation that when they melt down, the results aren't catastrophic (at least for the outside world).

Re: The Norway Problem

#310

Post by BlueTemplar »

lolinder wrote: post #158

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.

Yeah, I'd bet that YAML "two point oh" (rather than "two point zero") doesn't exist ! :p
Post reply on HN