Live data from Hacker News

In Defense of YAML

blog.atomist.com

61–70 of 173 posts

Re: In Defense of YAML

#61

While there are no other format with clear advantage over YAML, I wonder why nobody use javascript with modules as programmable configuration. Can be broken to file parts, support comment, variable, functions or scripts. And with additional extension can import packages. Though the downside may be JSON format that's noticably bigger than yaml.

I think JSON is almost always better than YAML, except for very simple cases.

Re: In Defense of YAML

#62

While we're writing the wrongs of badly specified interfaces, can we please kill this stupid obsession with "writing code" to get work done? Code is buggy . It's difficult to write well, you have to write 10,000 tests for it, you have to have a testing framework, complex procedures to move it through pipelines and roll it back and version control it and debug it and maintain it and deploy it. It's annoying. I don't w…

I can't tell if this is sarcastic or not, but it doesn't seem to be.

Binary computers are precise in their operation; that's why we use programming languages: to make it easier to create the underlying instructions to perform calculations. You are assuming that human answers to human questions in imprecise human language can even be converted to binary instructions. If it were that easy, general AI would've already been invented and self-driving cars would already exist.

Re: In Defense of YAML

#63
post #58
post #30

Earlier quoted context omitted.

From the YAML spec[1]: > Three dots ( “...”) indicate the end of a document without starting a new one, for use in communication channels [1] https://yaml.org/spec/1.2/spec.html#id2760395

Three dots indicates the end of a block, not a document. Look at Example 2.8 in your link. If the user sends; --- time: 20:03:20 player: Sammy Sosa action: strike (miss) ... .. you can't know if they actually meant to send .. --- time: 20:03:20 player: Sammy Sosa action: strike (miss) ... --- time: 20:03:47 player: Sammy Sosa action: grand slam ... Also, in my experience, which is mostly limited to Ansible config bec…

They mark the end of a YML "document", but not the end of a YML "stream", which can contain multiple documents. It's the terminology that's causing confusion.

Re: In Defense of YAML

#64
post #21
post #8

Earlier quoted context omitted.

I don't understand why people use a markup language when they need a programming language. I mean, sure, you can convert one into the other syntax-wise, both form trees, but what do you gain?

From what I've experienced, it's mostly tools that target either sysadmins or sysadmins-turned-pseudo-devops, and those tools pretend that anything can be done with 'just configuration' as a marketing point. Programming is for programmers, you see. It's easy for someone who never {wanted to, learned to} program to accept yet another configuration format (with all options specified up front) and then accidentally lear…

Would you expect all sysadmins to become programmers?

Re: In Defense of YAML

#65

While we're writing the wrongs of badly specified interfaces, can we please kill this stupid obsession with "writing code" to get work done? Code is buggy . It's difficult to write well, you have to write 10,000 tests for it, you have to have a testing framework, complex procedures to move it through pipelines and roll it back and version control it and debug it and maintain it and deploy it. It's annoying. I don't w…

I can't tell if this is sarcastic or not, but it doesn't seem to be. Binary computers are precise in their operation; that's why we use programming languages: to make it easier to create the underlying instructions to perform calculations. You are assuming that human answers to human questions in imprecise human language can even be converted to binary instructions. If it were that easy, general AI would've already b…

You're taking it too literally/assuming too much. It is super easy. Watch.

  $ awscli s3 ls
  Unable to locate credentials. You can configure credentials by running "aws configure".
That is stupid. Let's fix it.

  #!/bin/bash
  [ -r .awssettings ] && . .awssettings
  [ -n "$USERN" ] || read -p "What is your username? " USERN
  if [ ! -n "$PASS" ] ; then
      read -s -p "Enter your password: " PASS ; echo ""
  fi
  [ -n "$REGION" ] || read -p "What region should I run this in? " REGION
  echo awscli --region $REGION --user $USER --pass $PASS "$@" \
  && echo -en "USER=$USER\nREGION=$REGION\n" > .awssettings

  $ ./foo.sh s3 ls
  What is your username? peter
  Enter your password:
  What region should I run this in? us-east-1
  awscli --region us-east-1 --user peter --pass blahblah s3 ls

This is a contrived example, because of course AWS wants obscure tokens and secrets to log in, but the point is that it was trivial to write an interface that helped the user out. The fact that this isn't the default is stupid. (The argument that it fails by default to "help programs out" is dumb, because a simple argument like --no-questions which becomes default without a tty is easy)

Re: In Defense of YAML

#66
post #3

> This is not structured data. This is programming masquerading as configuration I find myself expressing this same opinion to people on a frequent basis. See ansible for another big example. Ansible has a try/catch equivalent in yaml [0]! Unfortunately, YAML is more or less a lowest common denominator for these sorts of interactions - being usable from any language is a really big boon. Would love to see the world a…

What about https://dhall-lang.org/ ?

Everything dhall advertises itself as useful for is basically as a replacement for situations where YAML has been abused or where the separation of concerns between code and config was improperly cut (this is largely how YAML files get to be mind numbingly repetitive).

It does this by creating something not quite as powerful as a real programming language (sometimes a feature; probably not here though) while still complicated enough to effectively be unreadable to an average Joe.

Re: In Defense of YAML

#67
I can't be the only one that sees the historical irony in Rod Johnson being the one to write up this opinion? (Then again, you could argue that he's speaking from experience.)

Over fifteen years ago I was in programming as configuration hell with Interface21, and later Spring-based enterprise Java stuff...

Re: In Defense of YAML

#68

I highly agree with inappropriateness of YAML for GitLab CI/CD configuration. It does work for simple use cases and/or in small repositories - however, doing something slightly more complicated than a simple build/test/deploy pipeline takes an immense effort, with a range of hacks and workarounds. Even the simplest things, like passing some data (e.g. a link) from one job to another requires quite an overhead (either…

GitLab PM for Verify (CI) here.

I agree that a lot of complex pipelines can be tough to express in YAML. One of our key focuses this year is to make advanced use cases for GitLab CI/CD more lovable. Specifically, you can see the overall direction here: https://about.gitlab.com/direction/verify/. Some specific issues I'd love feedback from the community on that I'm thinking about are:

* Directed acyclic graphs (DAG) for pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/47063

* Make it possible to use any language to generate `.gitlab-ci.yml` and pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/45828

* First class support for multiple pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/28592

* Self-modifying pipelines: https://gitlab.com/gitlab-org/gitlab-ce/issues/44199

(edited for readability)

Re: In Defense of YAML

#69

The YAML spec requiring turning "yes" "1" to true, and "no" "0" to false is one of the most aggravating things about YAML.

Also "on" and "off", and variations. "y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF" https://yaml.org/type/bool.html

"NO" being false is particularly fun:

    - languages:
      - en # english
      - is # icelandic
      - no # norwegian
      - ja # japanese
      - fr # french

    [{"languages": ["en", "is", false, "ja", "fr"]}]

Re: In Defense of YAML

#70
post #21

Earlier quoted context omitted.

From what I've experienced, it's mostly tools that target either sysadmins or sysadmins-turned-pseudo-devops, and those tools pretend that anything can be done with 'just configuration' as a marketing point. Programming is for programmers, you see. It's easy for someone who never {wanted to, learned to} program to accept yet another configuration format (with all options specified up front) and then accidentally lear…

Would you expect all sysadmins to become programmers?

Would it be beneficial? Yes. Is it necessary for most cases? No. I do think, however, the moment when you infrastructure becomes defined by code (eg. you start using any CM system) then you should be training your sysadmins to program more and duct tape existing solutions less. Operations become vastly easier to scale and maintain if you can defer their logic to actual services with clearly defined business logic rather than a mess of ansible configs and bash scripts.
Post reply on HN