The Norway Problem • Hacker News Board

Re: The Norway Problem

#271

Post by mcv » Sat, Apr 03, 2021, 8:41 PM UTC

marcinzm wrote: post #173

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.

That makes a big difference indeed. It wasn't clear to me from the article, but string yaml + optional schema sounds like a useful combination.

Re: The Norway Problem

#272

Post by jrockway » Sat, Apr 03, 2021, 8:47 PM UTC

unionpivo wrote: post #205

lixtra wrote: post #187

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

> 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. Computer overheating? Unplug it. With this in mind, "assert" transitions the system from an undefined state to an inoperative state, which is safer.

That isn't to say that that you want bugs in your code, and that energizing some system is free of consequences. Your emergency stop of your mill just scrapped a $10,000 part. Unplugging your server made your website go down and you lost a million dollars in revenue. But, it didn't kill someone or burn the building down, so that's nice.

Re: The Norway Problem

#273

Post by gitowiec » Sat, Apr 03, 2021, 8:58 PM UTC

I don't like YAML because when I need to write configuration in it I waste time to remember what is the syntax. I have much better understanding of JSON, because I use it almost on daily basis.

Re: The Norway Problem

#274

Post by MrPatan » Sat, Apr 03, 2021, 9:03 PM UTC

takeda wrote: post #262

MrPatan wrote: post #245

Earlier quoted context omitted.

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

Because it offered all these things parent responded, but that made it too complex. You either provide schema and get commodities of describing it or you don't. I had a chance of using SOAP at one point. It was a F5 device and I used a python library. What I really liked is that when it connected to it it downloaded its schema, and then used that to generate an object. At that point you just communicated with device…

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 get a few properties of a bunch of entities in a bigger XML document, that's all. Big fail.

Second, JSON always had a parser in JS, so I don't know where that eval nonsense is coming from.

Third, JS actually had the best dev UX for XML of all languages 20 years ago. Maybe you know JavaScript from Node.js, but 20 years ago it used to run excusively in web browsers, which even then were pretty good at parsing XML documents. The browser of course had a JS DOM traversal API known to every single JS developer, and very soon (Although TBH I can't remember if before or after JSON) it also had xpath querying functions, all built in.

XML was so bad, that its replacement came from the language where it was actually easiest to use. think about that for a second.

So the answer to the question "Why was XML replaced?" is not "Because webdevs lol".

I suspect it was because it has both content and attributes, which all but guarantees it's impossible to create a bunch of simple, common data structures from it (like JSON does).

Re: The Norway Problem

#275

Post by lixtra » Sat, Apr 03, 2021, 9:04 PM UTC

WalterBright wrote: post #256

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…

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

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

I ask you to reconsider your assumptions. How did this play out in the 737 MAX crashes? Was there a backup AoA sensor? Did MCAS properly shut down and backup engaged? Was manual overriding the system not vital knowledge to the crew?

You don’t have to answer. I probably wouldn’t get it anyway.

But rest assured that I won’t try to program flight control and I strongly appreciate your strive for better software.

Re: The Norway Problem

#276

Post by samatman » Sat, Apr 03, 2021, 9:10 PM UTC

ufo wrote: post #189

atleta wrote: post #77

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

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

Lua does have semicolons!

It even has semicolon insertion, but because the language is carefully designed, this doesn't cause problems, and most users can go a lifetime without knowing about it.

Our coding style requires semicolons for uninitialized variables, so you'll see

    local x;
    if flag then
       x = 12 
    else
       x = 24
    end

As a way of marking that the lack of initialization is deliberate. `local x = nil` is used only if x might remain nil.

Re: The Norway Problem

#277

Post by tjalfi » Sat, Apr 03, 2021, 9:13 PM UTC

goatinaboat wrote: post #91

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…

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. It's a bad idea because ASCII already includes dedicated characters for field separator, record separator and so on. These could easily be made displayable in a text editor if you wanted just as you can display newlines as ↲. Anyone who invents a format that involves…

> It's a bad idea because ASCII already includes dedicated characters for field separator, record separator and so on.

ASCII is over 60 years old and separators haven't caught on yet; what's different now?

> These could easily be made displayable in a text editor if you wanted just as you can display newlines as ↲.

Can you name a common text editor with support for ASCII separators? It's a lot easier to use delimiters and escaping then change every text editor in the world.

> Anyone who invents a format that involves using normal printable characters as delimiters and escaping them when you need them, is, I feel very confident in saying, grotesquely and malevolently incompetent and should be barred from writing software for life. CSV, JSON, XML, YAML, all guilty.

All of the formats you rant about are widely used, well supported, and easy to edit with a text editor - none of these are true of ASCII separators. People chose formats they can edit today instead of formats they might be able to edit in the future. All of these formats have some issues but none of the designers were incompetent.

Re: The Norway Problem

#278

Post by WalterBright » Sat, Apr 03, 2021, 9:14 PM UTC

lixtra wrote: post #275

WalterBright wrote: post #256

Earlier quoted context omitted.

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

> 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. I ask you to reconsider your assumptions. How did this play out in the 737 MAX crashes? Was there a backup AoA sensor? Did MCAS…

> How did this play out in the 737 MAX crashes?

They didn't follow the rule in the MCAS design that a single point of failure cannot lead to a crash.

> Was manual overriding the system not vital knowledge to the crew?

It was, and if the crew followed the procedure they wouldn't have crashed.

Re: The Norway Problem

#279

Post by diggan » Sat, Apr 03, 2021, 9:15 PM UTC

gnud wrote: post #264

mc10 wrote: post #208

Earlier quoted context omitted.

S-expressions are super easy to parse and are fairly easy for humans to read. See e.g. using s-expressions in OCaml: https://dev.realworldocaml.org/data-serialization.html

S-expressions inherits all trouble with data types from json (dates, times, booleans, integer size, number vs numeric string). You get neat ways of nesting data, but that is not enough for a robust and mistake-resilient configuration language. The problem isn't parsing in itself. The problem is having clear sematics, without devolving into full SGML DTDs (or worse still, XML schemas).

> S-expressions inherits all trouble with data types from json (dates, times, booleans, integer size, number vs numeric string).

Hm, not sure that's true, S-expressions would only define the "shape" of how you're defining something, not the semantics of how you're defining something. EDN https://github.com/edn-format/edn for all purposes is S-expressions and have support for custom literals and more, to avoid "the trouble with data types from JSON"

Re: The Norway Problem

#280

Post by dragonwriter » Sat, Apr 03, 2021, 9:44 PM UTC

medstrom wrote: post #267

dragonwriter wrote: post #254

Earlier quoted context omitted.

“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?

From the article: > The most tragic aspect of this bug, howevere, is that it is intended behavior according to the YAML 2.0 specification.

The article is simply, factually wrong; there is no “YAML 2.0 specification” [0], and everything they point to is YAML 1.1, and addressed in YAML 1.2 (the most recent YAML spec, from 2009.)

[0] https://yaml.org/