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

221–230 of 339 posts

Re: The Norway Problem

#221

Post by ng12 »

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

Jsonnet hasn't taken off because it's turing complete. It's a really great language for generating JSON but not a replacement for JSON.

Re: The Norway Problem

#222

Post by diggan »

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

Seems you're missing my personal favorite, extensible data notation - EDN (https://github.com/edn-format/edn). Probably I'm a bit biased coming from Clojure as it's widely used there but haven't really found a format that comes close to EDN when it comes to succinctness and features.

Some of the neat features: Custom literals / tagged elements that can have their support added for them on runtime/compile time (dates can be represented, parsed and turned into proper dates in your language). Also being able to namespace data inside of it makes things a bit easier to manage without having to result to nesting or other hacks. Very human friendly, plus machine friendly.

Biggest drawback so far seems to be performance of parsing, although I'm not sure if that's actually about the format itself, or about the small adoption of the format and therefore not many parsers focusing on speed has been written.

Re: The Norway Problem

#223

Post by yyyk »

kstenerud wrote: post #52
anticristi wrote: post #29

Earlier quoted context omitted.

This makes me sad. It's 2021 and we still haven't figure out how to serialize configuration in a format that is easy-to-edit and predictable.

This is the problem space I'm targeting with https://concise-encoding.org/ * Text AND binary so that humans can edit easily, and machines can transmit energy and bandwidth efficiently. * Carefully designed spec to avoid ambiguities (and their security implications). * Strong type support so you're not using all kinds of incompatible hacks to serialize your data. * Versioned, because there's no such thing as the perfe…

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

- Not a fan of octal notation. At 3am not sure I can't confuse 0 and o given certain fonts. Does anyone even use it these days?

- Unquoted string were discussed in the thread, I'd like to point out that it's very easy to make an unquoted string not "text-safe" (according to the spec) without noticing it, at which point document is invalid.

Just add white-space (maybe a user pasted a string from somewhere without noticing whitespace at the end or forgot the rules), a dot, an exclamation or a question mark. Having surprises like that is IMHO worse than a consistent quoting method.

Basically all the things I don't like are about the format supporting a bit too much. YAML 1.1 should teach us more is sometimes less.

Re: The Norway Problem

#224

Post by korijn »

blunte wrote: post #162

If you want no misunderstandings, be explicit. This applies to YAML and life in general. There's an annoying but fairly accurate saying about assumptions that applies. If you want something to be a specific type, you better have an explicit way of indicating that. If you say quotes will always indicate a string, great. Of course we know it's not that simple, since there are character sets to consider. The safest answ…

Or just opening your browser and trying out norwegian on a QA environment.

Re: The Norway Problem

#225

Post by orthoxerox »

geraldbauer wrote: post #198
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)…

You might look at JSON Next variants (if you remember - "classic" JSON is a subset of YAML), see https://github.com/json-next/awesome-json-next My own little JSON Next entry / format is called JSON 1.1 or JSONX, that is, JSON with eXtensions, see https://json-next.github.io

The list is missing http://www.relaxedjson.org/

Also, there's no explanation what and do.

Re: The Norway Problem

#226

Post by rubyn00bie »

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:

email - noun

name - noun

birthday - noun

It says next to nothing except, yes, they are nouns. All too often I waste time fighting nils and bullshit in fields or duplicating validation logic all over the place.

"Oh wow, this field... is a string..? That's great... smiles gently except... THERE SHOULD NOT BE EMOJI IN MY FUCKING UUID, SCHEMA-CHUD. GET THE FUCK OFF MY LAWN!"

Re: The Norway Problem

#227

Post by hansvm »

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 programming languages has discrepancies in minint, maxfloat, datetime, timezone, round-tripping, max depth, and all kinds of other nuanced issues. Existing tooling is nice when it does what you expect, but for a no-frills, no-surprises configuration language I would almost always just prefer to use the programming language itself or otherwise write a parser if that doesn't suffice (e.g., in multilingual projects).

Mildly off-topic: The problem here, more or less, was that the configuration change didn't have the desired effect on an in-memory representation of that configuration. We can mitigate that at the language level, but as a sanity check it's also a good idea to just diff the in-memory objects and make sure the change looks kind of like what you'd expect.

Re: The Norway Problem

#228

Post by atombender »

svnpenn wrote: post #214
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)…

You seem pretty quick to disregard TOML. I switched all my JSON and YAML for TOML. Do you care to detail what is missing?

TOML quickly breaks down with lots of nested arrays of objects. For example:

    a:
      b:
      - c: 1
      - d:
        - e: 2
        - f:
            g: 3
Turns into this, which is unreadable:

    [[a.b]]
    c = 1

    [[a.b]]
    [[a.b.d]]
    e = 2

    [[a.b.d]]
    [a.b.d.f]
    g = 3
TOML also has a few restrictions, such as not supporting mixed-type arrays like [1, "hello", true], or arrays at the root of the data. JSON can represent any TOML value (as far as I know), but TOML cannot represent any JSON value.

At my company we use YAML a lot for table-driven tests (e.g. [1]), and this not only means lots of nested arrays, but also having to represent pure data (i.e. the expected output of a test), which requires a format that supports encoding arbitrary "pure" data structures of arrays, numbers, strings, booleans, and objects.

[1] https://github.com/sanity-io/groq-test-suite/

Re: The Norway Problem

#229

Post by atombender »

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…

You don't need wide adoption for internal projects in an organization, but you do want great toolchain support.

For example, the fact that NestedText is a Python library means a Python team could use it, but it's a poor fit for an organization whose other teams use Go and JavaScript/TypeScript.

We use YAML for much more than configuration, by the way. I feel like YAML hits a nice sweet spot where it's usable for almost everything.

Re: The Norway Problem

#230

Post by dragonwriter »

atombender wrote: post #184
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…

> You're right, but it's worth noting that much of the world is still on YAML 1.1

This is an article justifying use of (and justifying design decisions of) a particular Python quasi-YAML parsing library. If you are in a position to select a non-YAML-1.1-compliant parsing library for Python, or to take the articles advice on design of a YAML(-ish) parsing library, you are, necessarily, not stuck with YAML 1.1.

> for whatever reason

Articles like this spreading misinformation about the current state of standard YAML are part of the reason. LibYAML lagging support is another since so much of the ecosystem depends on libYAML (though, while the documentation situation is terrible, it looks like maybe libYAML has some level of 1.2 support since 0.23.)

> For example, Ruby's standard library only supports YAML 1.1. It relies on libyaml, [...] Python's popular PyYAML library only supports 1.1

Which, also, is dependent on libYAML.

> and asks users to migrate to a newer fork called ruamel.yaml for 1.2 support.

Which makes a lot more sense than migrating to a library thar supports neither 1.1 nor 1.2, but a nonstandard variant that addresses some of the same issues resolved years ago in 1.2, especially when a library supporting 1.2 is available for the same language.

Post reply on HN