YAML? That's Norway Problem

JSR_FDED•5 minutes ago

Somehow my brain finds YAML hard to parse. JSON is easy but ugly. Lately I’ve just been using Python code in a module to initialize config settings. Initially it was just a lazy way to get started, but having the flexibility of an actual language is great when things evolve over time.

al_borland•2 days ago

For yaml in the context of Ansible, this was recently fixed a little while back in v2.19.

They got more strict about booleans. For those who need/want the old behavior, ALLOW_BROKEN_CONDITIONALS can be set in the ansible.cfg or `is truthy` can be used for python-like version, but it becomes explicit vs being implied.

bfung•about 1 hour ago

Really? Putting quotes around strings is called escaping now?

    One workaround is to escape the string, like this:
    
    countries:
      - DE
      - FR
      - "NO"
      - PL
      - RO

Comon, it’s 2026, yeah yaml’s design can lead to odd type casts, but a whole essay on this? Keep it under 140 chars pls.

somat•2 minutes ago

Also YAML fixed this in (checks spec) 2009 with the 1.2 version. If projects want to keep using old spec that's not yamls fault.

I have doubts about the over all utility of yaml. I am not sure how readable it is over well formed json. and my main exposure to it is ansible which suffers from the inner platform effect where in order to save us from programming a programming language is jammed into a non programming language(usually XML but in this case YAML) and every one is more miserable for the experience. But complaining about a thing that is fixed is wierd.

rpreetha•2 days ago

Was backward compatibility the main reason YAML kept these implicit conversions for so long, or was there a stronger usability argument originally?

nalekberov•about 2 hours ago

YAML is the worst format.

You are literally one missing tab away from breaking your entire configuration file. Yet the industry keeps pushing it for the sake of “simplicity” - for small configurations sure, it’s fine, but many hundred lines of config entries? Good luck fixing it, if something goes wrong.

I still can’t get why software engineers suddenly started to hate XML.

deepsun•about 2 hours ago

Long time ago i thought .properties was bad, as it has no structure. But later I realized repeating full path to every config param is really good for readability, and code reviews.

The only thing I wish it had is @import-s from a separate files, that way we could split local/checkedin configs. YAML doesn't have @imports as well (only rudimentary from the same file), I have only seen them at HOCON.

Bolwin•about 1 hour ago

Cause it's very verbose. A lot more syntax to break.

I personally think the best is one of the humanized json ones like https://maml.dev/

ThunderSizzle•about 1 hour ago

It wouldn't need to be if closing tags were allowed to be unnamed. For most cases, we can tell the closing tags easily enough for simpler files:

  <project>MAML</>
  <tags>
    <item>minimal</>
    <item>readable</>
  </>
  
  <!-- A simple nested object -->
  <spec>
    <version>1</>
    <author>Anton Medvedev</>
  </>

  <!-- Array of objects -->
  <examples>
    <item>
      <name>JSON</>
      <born>2001</>
    </>
    <item>
      <name>MAML</>
      <born>2025</>
    </>
  </>

  <notes>
  This is a multiline raw strings.
  Keeps formatting as-is.
  </>

tremon•8 minutes ago

But if closing tags are allowed to be unnamed, you are still one misplaced </> away from unrecognizably maiming the entire hierarchical structure, just like one incorrect indent can do in YAML.

Ultimately, what matters is the editing mode and not the data format. Good syntax highlighting and autocompletion goes a long way towards safely editing structured text, regardless of on-disk format.

eviks•10 minutes ago

This is still noisy, wasting 3 symbols to end where an invisible line end would suffice

gfody•about 2 hours ago

https://ohyaml.wtf

YAML? That's Norway Problem

⚡ Community Insights

Discussion (12 Comments)Read Original on HackerNews