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

251–260 of 339 posts

Re: The Norway Problem

#251

Post by jhomedall »

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…

F#, Kotlin, Python, Nim and many others all seem to get by fine without semicolons as statement terminators.

Re: The Norway Problem

#252

Post by [deleted] »

MrPatan wrote: post #245
fmakunbound wrote: post #240

Earlier quoted context omitted.

XML and XML Schema solved this more than 20 years ago. It had to be replaced with JSON by the web developers though, so they could just “eval() it” to get their data.

If all the smart people like you used XML, how come it was so painful to use and it died?

[deleted]

Re: The Norway Problem

#253

Post by WalterBright »

jhomedall wrote: post #251
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…

F#, Kotlin, Python, Nim and many others all seem to get by fine without semicolons as statement terminators.

In Python, a newline is a token and serves as a statement terminator.

What I'm referring to is the notion that:

    a = b c = d;
can be successfully parsed with no ; between b and c. This is true, it can be. But then it makes errors difficult to detect, such as:

    a = b
    *p;
Is that one statement or two?

Re: The Norway Problem

#254

Post by dragonwriter »

tormeh wrote: post #246
dragonwriter wrote: post #243

Earlier quoted context omitted.

> The world desperately needs a replacement for YAML. The world desperately needs support for YAML 1.2, which solves the problems the article addresses fairly completely (largely in the “default” Core schema[0], but more completely with the support for schemas in general), plus a bunch of others, and has for more than a decade. But YAML 1.2 libraries aren’t available for most languages. [0] not actually an official d…

Nope nope nope. YAML is awful and needs to die. The more you look at it the worse it gets. The basic functionality is elegant (at least until you consider stuff like The Norway Problem), but the advanced parts of YAML are batshit insane.

“The Norway Problem" is a YAML 1.1 problem, of which there are many.

What advanced parts of YAML are you talking about that remain problems in YAML 1.2?

Re: The Norway Problem

#255

Post by scythe »

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…

If you want automatic built-in string validation, one option that seems particularly interesting is to use a variant of Lua patterns, which are weaker and easier to understand than regular expressions, but still provide a significant degree of "sanity" for something like an email. The original version works on bytes and not runes, but you could simply write a parser that works on runes instead, and the pattern-matching code is just 400 old and battle-tested lines of C89. You might want to add one extension: allow for escape sequences to be treated as a single character (hence included in repetition operators and adding the capability to match quoted strings); with this extension, I think you could implement full email address validation:

https://i.stack.imgur.com/YI6KR.png

Lua patterns have also shown up in other places, such as BSD's httpd, and an implementation for Rust:

https://www.gsp.com/cgi-bin/man.cgi?section=7&topic=PATTERNS

https://github.com/stevedonovan/lua-patterns

http://lua-users.org/wiki/PatternsTutorial

Re: The Norway Problem

#256

Post by WalterBright »

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…

Your rationale in this and your followups are exactly what I'm talking about.

1. You're actually right if the entire program is less than about 20 lines. But bad programs always grow, and implicit declaration will inevitably lead you to have a bug which is really hard to find.

2. The trouble comes from programmer typos that turn out to be real syntax, so the compiler doesn't complain, and people tend to be blind to such mistakes so don't see it. My favorite actual real life C example:

    for (i = 0; i
My friend who coded this is an excellent, experienced programmer. He lost a day trying to debug this, and came to me sure it was a compiler bug. I pointed to the spurious ; and he just laughed.

(I incorporated this lesson into D's design, spurious ; produce a compiler error.)

3. I used to work for Boeing on flight critical systems, so I speak about how these things are really designed. Critical systems always have a backup. An assert fail means the system is in an unknown, unanticipated state, and cannot be relied on. It is shut down and the backup is engaged. The proof of this working is how incredibly safe air travel is.

Re: The Norway Problem

#257

Post by Arnavion »

tgv wrote: post #56
Arnavion wrote: post #20

Earlier quoted context omitted.

They all have their downsides. JSON: - no comments, unless you fake them with fake properties, unless your configuration has a schema that doesn't allow extra fake properties - no trailing commas; makes editing more annoying - no raw strings YAML: - the automatic type coercion - the many ways to encode strings ( https://yaml-multiline.info/ ) - the roulette wheel of whether this particular parser is anal about two-sp…

> - the automatic type coercion Only when you "unmarshal" to an untyped data structure and then make assumptions about the type. I've used yaml with a go application, and it can't interpret NO as a bool when the field is a string.

Correct, like TFA.

Re: The Norway Problem

#258

Post by WalterBright »

lixtra wrote: post #187
unionpivo wrote: post #175

Earlier quoted context omitted.

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…

See my previous reply. Your reactor design is susceptible to a single point of failure, and, how do I say it strongly enough, is an utterly incompetent design. Bypassing assertions is not the answer.

Re: The Norway Problem

#259

Post by yyyk »

kstenerud wrote: post #232
yyyk wrote: post #223

Earlier quoted context omitted.

+ Has binary format. + Avoids ambiguities. - The format seems to feel the need to support everything , including things I am not sure are actual usecases (what's the point of Markup element for example? What does Metadata save us compared to just including it in document, given that parsers must parse it anyway?). This must make implementation most complex and costly, and makes reading the text format more difficult.…

Alright that's two votes against unquoted strings so far (plus my wife agrees so that's three against!) I put in octal because it was trivial to implement after the others. The canonical format when it's stored or being sent is binary, and a decoder shouldn't be presenting integers in octal (that would just be weird). But a human might want octal when inputting data that will be converted to the binary format. Markup…

Well, unquoted strings work when a format is built for that. If the default was "it's text unless we see the special sequences" it would be better for unquoted strings. But even then there are too many special characters in this format IMHO.

I saw there's a 'Media' type in the spec. It's seems the type is actually for serializing files. But there's no "name" (or we can call it "description") field. Of course we could accomplish this with a separate field - but than again the entire type's functionality could be accomplished with a u8x array and a string field. So if you're specifying this type at all, might as well add a name field to make it useful.

Re: The Norway Problem

#260

Post by joshgachnang »

fmakunbound wrote: post #240
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)…

XML and XML Schema solved this more than 20 years ago. It had to be replaced with JSON by the web developers though, so they could just “eval() it” to get their data.

All except the easily written by humans part. Which is kind of a key part.
Post reply on HN