
No: Body: Wants: To: Write: – YAML - ghuntley
https://noyaml.com
======
jfaucett

        No:
    	Body:
    		Wants:
    			To:
    				Write:
    					- YAML
    

vs.

    
    
        <No>
            <Body>
                <Wants>
                    <To>
                         <Write>
                             <item>YAML</item>
                         </Write>
                    </To>
                </Wants>
            </Body>
        </No>
    

vs.

    
    
        {
           "no" : {
              "body" : {
                  "wants" : {
                     "to" : {
                        "write" : [ "YAML" ]
                      }
                   }
               }
           }
        }
    

Which would you rather write?

~~~
krapp
It's a bit of a strawman, since none of your examples actually resemble valid
config files and you're forcing them all to have the same indentation, when
significant whitespace only matters in YAML.

~~~
hahamrfunnyguy
That, not too mention how often do you actually write data files by hand?
Maybe a small sample file for testing, but beyond that all data is going to be
read in from files or come from an API.

JSON is not bad to write by hand. Simple XML isn't too bad either, but I still
prefer JSON.

~~~
hiyer
JSON doesn't have comments. If I want to know why a config has a particular
value, I can write a comment to explain it in YAML or xml, just like I would
do in code. Lack of comments is the primary reason I would not use json for
anything that needs to be written or read by humans.

------
ebiester
I want to write YAML because I don't want my configuration to look
significantly different in go, java, ruby, or any other language my
organization may use in the future.

Xml is fine. Json is fine. Yaml is fine. Yes, they have warts. That's fine
too.

~~~
simcop2387
For most things lately I've been using TOML because it gets me that, and it's
a relatively simple (to a human) standard. Combined with there being parsers
and emitters in just about every language now, it's a great option. You get
sections in the config that map easily to native data structures in the
languages, good string handling, can create a few more advanced things like
arrays (really useful for adding multiple ports or listening addresses, etc.).

I do still use YAML on the rare occasion where i just don't like how the TOML
ends up looking[1]. My plan with that example is to eventually make a more
simplist DSL that can handle the usecase, but my first attempts didn't produce
anything I liked.

[1] [https://github.com/perlbot/App-
EvalServerAdvanced/blob/maste...](https://github.com/perlbot/App-
EvalServerAdvanced/blob/master/skel-sandbox/etc/seccomp.yaml)

------
crad
I like YAML. It's ok if you don't. It's ok that I do. Want to use TOML?
Awesome. Want to use JSON? Go for it. I prefer YAML, it works for me and I'll
keep using it until something better comes along that I like.

Preference is preference. Stop acting like it's not. This page might have been
"Nobody wants to use VI" or "Nobody wants to use Emacs" or "Nobody wants to
use [insert thing I hate here]"

~~~
ghuntley
With Emacs vs VI we have a choice.

Kubernetes...devops tooling...CloudFormation?

You better <3 YAML.

~~~
crad
So lobby those projects to add more support. Heck, make a PR to add the
serialization language of your choice. Start coding. If they don't want
patches for "[insert data serialization formation here]", maintain your own
fork.

FWIW CloudFormation _added_ YAML, which was a vast improvement to usability
IMO over where they started. Want CloudFormation to support something else?
Lobby through your AWS account rep for what you want supported.

~~~
ghuntley
I agree with what you are saying but the boat has sailed. Just like decisions
with the SMTP protocol in the early years where folks can fake the FROM field
thus causing the issues we experience every day the same is true with devops
and yaml. Forever:Drowning:In-YAML.

------
j1elo
Requires Javascript to even start showing the text. That "live" editor trick
is neat, but pretty unnecessary to transmit the message, if you ask me. Also
there are some good-old links that are not even clickable. Weird choice of
tool for the job.

~~~
ghuntley
Just as YAML provides no validation document, intellisense or type safety this
website is designed to be a hindrance. It's part of the message to make the
experience more real. I do accept PRs tho so mash the octocat.

~~~
mnr
Challenge.

------
Jedd
> We replaced 1,000 lines of YAML with 10 structs ...

I looked, but target URL didn't spell it out, and I lack sufficient domain
knowledge to dive into the repo to find it -- but I'm curious as to how big,
and indeed how complex, those 10 structs are.

It seems disingenuous to swap units mid-sentence when comparing size or
complexity.

My gut feel is the set of people who could understand thoughtfully designed
YAML should be larger than the set of people who could understand thoughtfully
designed structs (+ wrappers?).

~~~
ghuntley
This quote was taken from a kubernetes retrospective at
[https://about.sourcegraph.com/go/valuable-lessons-in-over-
en...](https://about.sourcegraph.com/go/valuable-lessons-in-over-engineering-
the-core-of-kubernetes-kops/#what-did-they-remove-exactly/)

Scroll to the bottom:

In a nutshell, they got rid of a custom programming language they had
inadvertently created via YAML and text/template. Their YAML models were
effectively written in a Turing-complete language composed of YAML and
text/template directives. They had been heavily abusing the FuncMap type in
text/template.

~~~
Jedd
Thanks, and yes, I did read through that page. Lots of coloured text that
tantalisingly looked like links but weren't, and a lot of broken
images/slides.

I got to
[https://github.com/kubernetes/kops](https://github.com/kubernetes/kops) ...
and that's where I got out of my depth.

It _sounds_ like it wasn't a problem with YAML per se, but their
misappropriation of text/template and wrangling YAML to be something other
than a configuration tool. It feels similar to if I were to complain about the
shortcomings & complexity of the jinja2 constructs I make within my YAML.

~~~
ghuntley
Ah yes but please revisit this problem space from the perspective of a
consumer of YAML. Ops folks are drowning in it. The industry can and should do
better.

------
allochthon
YAML is not 100 percent awesome, but it's machine consumable, not too hard to
edit by hand, and preferable (in my opinion) to a plethora of application
specific DSLs with different requirements for curly braces, semicolons and
assignment operators.

------
beaker52
I always struggle to write YAML. I still don't know how the '-' things work
and what level of indentation to use for its children.

~~~
shriek
My go-to tool to see what yaml will look like. [http://nodeca.github.io/js-
yaml/](http://nodeca.github.io/js-yaml/)

------
ljnelson
One of the lovely bits I ran into recently is whether a given YAML parser
interprets a value as a string or not (for example) is entirely up to the
parser, and there's nothing you can really do about it in the syntax. Quoting
is a useful hint, but the parser doesn't have to take action as a result.
!!str is another useful hint, but str is kind of up to the parser. My favorite
related bug that shows the kind of shenanigans that simply using YAML results
in:
[https://github.com/kubernetes/helm/issues/1707](https://github.com/kubernetes/helm/issues/1707)

------
yebyen
Did I read correctly that YAML is a superset of JSON?

> This means that, in theory at least, a YAML parser can understand JSON

Does anyone have experience with this? It seems counter-intuitive at first,
but Google agrees, and I don't know enough about parsers to say it's wrong.
Can you really feed pretty much any JSON file into a YAML parser and get back
a valid and correct, properly formed data structure?

~~~
ChrisSD
The explicit goal of yaml 1.2 was to fix up any incompatibilities with json.

[http://yaml.org/spec/1.2/spec.html](http://yaml.org/spec/1.2/spec.html)

------
Avi-D-coder
This site is unusable on mobile. I can't even follow the links.

~~~
cortesoft
The links don't work on desktop, either. It isn't a mobile thing.

~~~
ghuntley
The links are:

[https://tinyurl.com/lessons-in-over-engineering](https://tinyurl.com/lessons-
in-over-engineering) and
[https://twitter.com/ellism/status/1008728148131733504](https://twitter.com/ellism/status/1008728148131733504)

I accept accessibility PRs. Mash the octocat.

------
xellisx
Earlier Related Post:
[https://news.ycombinator.com/item?id=17358103](https://news.ycombinator.com/item?id=17358103)

------
yellowapple
YAML's like democracy: it's the worst option aside from all the others.

That said, I'm partial to s-expressions and TOML nowadays.

------
meowface
I love YAML and I don't care what anyone else thinks. For simple config files,
I use INI (could use TOML, I suppose). For anything beyond that, I use YAML.
It's easy to read, parse, write, and maintain. I just use the subset that's
relatively straightforward (no & ! --- sigil vomit).

------
andrewstuart
Here's someone who _really_ has been hurt by YAML. I've never used it but it's
good to know to steer clear in case I encounter it as an option.

------
timwis
There is literally no way to click those links on an Android phone. They're
not clickable and I can't even highlight them to copy and paste.

------
api
I've never liked YAML. It's one of the things that turned me off from Swagger.
It's incredibly ugly and overly complex.

------
TooBrokeToBeg
use it almost every day. it's an ugly little notation with super-limited
utility, but when JS gets its act together, we can finally abandon it forever.

------
Dig1t
This website is a little too dope for me.

------
hyperbole
Or: Read: It:

------
damm
What a stupid argument that is not worth the time.

------
tomc1985
What is this, bag-on-YAML day at HN?

I am really beginning to hate programmer-centric tooling. It has turned all of
us into these miserable, cretinous engineering snobs. It seems impossible for
anyone to contemplate why people would choose to work differently than them.
Zero empathy. Fucking pathetic.

Make software hard again, I say. Treat the compiler like you would treat your
dominatrix. Life would be so much better that way!

~~~
iainmerrick
At least the other link was a clear, well-written, well-reasoned article. I
have no idea what this one is.

~~~
PlanarFreak
I'm with you on this one. I enjoyed reading the arp242 article, but this one's
like a bad meme - an incomprehensible mish-mash of links and emojis.

~~~
seandougall
Not to mention fatal JS errors on mobile.

