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

181–190 of 339 posts

Re: The Norway Problem

#181

Post by lokedhs »

joshxyz wrote: post #43

This is why i love JSON. It's only string, number, boolean, arrays, objects/dictionaries, unless you write custom serializer and deserializers..

Except that its numbers are underspecified and cannot be used safely outside of a certain range. The spec explicitly states that the precision of numbers is not defined, meaning that N and N+1 may be the same number, and its behaviour would depend on the parser you're using.

The number one rule when creating a serialisation format should be that serialisation and deserialisation is predictable. It's quite remarkable that two of the most popular formats doesn't do this.

I'm actually surprised we haven't seen any major security issues caused by this.

Re: The Norway Problem

#182

Post by lisper »

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…

>> [...] 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.

Ironically, this did not render the way you intended because HN interpreted the asterisk as an emphasis marker in this line.

It works here:

    ... type 'delete *$' twice.
because the line is indented and so renders as code, but not here:

> ... type 'delete $' twice.

because the subsequent line has emphasized text*. So the scoping of the asterisks is all screwed up.

Re: The Norway Problem

#183

Post by zomglings »

Have had a similar issue when adding git revisions to YAML documents.

The problem is that if a YAML parser sees a string like this:

"0123e04"

It interprets it as a number: 123 * 10^4

Our hacky solution was to prefix the revision hashes like sha-0123e04, but still this was quite annoying.

After that experience, I have stopped using YAML for any of my own configuration. Have started preferring putting my configurations in code. And when I don't want that, have found JSON good enough for my purposes.

Re: The Norway Problem

#184

Post by atombender »

dragonwriter wrote: post #72

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.

You're right, but it's worth noting that much of the world is still on YAML 1.1, for whatever reason, so in practice, these are actual problems that will be encountered in the real world.

For example, Ruby's standard library only supports YAML 1.1. It relies on libyaml, which is not yet compliant with 1.2. Meanwhile, Python's popular PyYAML library only supports 1.1, and asks users to migrate to a newer fork called ruamel.yaml for 1.2 support.

Re: The Norway Problem

#185

Post by roland35 »

m463 wrote: post #30
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…

slightly related, on my microwave 99 > 100, even 61 > 100

I try to optimize my microwave button pushing too. I also have a +30 seconds button, so for 1:30 I can hit "1,3,0,Start" or "+30" three times and save a press!

Re: The Norway Problem

#186

Post by fanf2 »

grenoire wrote: post #8
mseepgood wrote: post #7

Earlier quoted context omitted.

A Ms True also broke Apple's iCloud: https://twitter.com/RachelTrue/status/1365461618977476610

That looks like an interesting hard-coded check, I wonder what it intended to fix.

There’s some analysis in this twitter thread: https://twitter.com/badedgecases/status/1368362392573317120

tl;dr: there are a bunch of fields of various types that arrive as strings, and they get coerced but without paying attention to which field should have which type

Re: The Norway Problem

#187

Post by lixtra »

unionpivo wrote: post #175
lixtra wrote: post #65

Earlier quoted context omitted.

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

Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits.

Downvote me if you want to open a bug ticket with the vendor and wait a week for the fix.

Upvote me if you’d give it a try to restart with a switch to ignore assertions.

You may abstain if you never shipped a bug.

Edit: not to forget that this website runs on lisp which violates all three. Was it really a bad choice for the website?

Re: The Norway Problem

#188

Post by pedrovhb »

lelanthran wrote: post #157
nightcracker wrote: post #139

Earlier quoted context omitted.

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.

Honestly, the rule is "don't use semicolons in Python". I don't think there's a single one in the large codebase I work with, and there's really no reason at all to use it other than maybe playing code golf.

It's not a language in which you ever need be saving bytes on the source code. Just use a new line and indent. It's more readable and easier.

Re: The Norway Problem

#189

Post by ufo »

atleta wrote: post #77
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.)

Another inreresting example is Lua. It's a free form language without semicolons. It's not indentation sensitive.

Re: The Norway Problem

#190

Post by anticristi »

sergeykish wrote: post #134
anticristi wrote: post #42

Earlier quoted context omitted.

I used XML and didn't like it: - A proper editor was never around. - Closing tags were verbose. - Attributes vs tags was confusing. - It didn't map "naturally" to common data types, like lists, maps, integers, float, etc.

You've just used XML tech as it was designed to post this comment. XML is serialization. I hardly believe you was concerned about serialization while posting comment or thought about attributes-tags distinction. This page utilizes request to server for multi-user editing. But it is easy to build truly serverless (like a file) document with same interface: data:text/html, Host: example.com Change it, save it, done. We…

You are right. XML is great for encoding the DOM. However, I didn't find it practical for interfacing with humans, due to the concerns I raised.
Post reply on HN