XML is better than YAML

Re:XML is better than YAML by gorgoiler on Thursday September 21, 2023 @12:52AM (#37593359)

Configuration through code requires a lot of organisational discipline. That’s easy to do if it’s just you and your own code. It’s easy if you have good social connections between the people who review each others code (and you also have code review.)

One bad apple can ruin everything though:

  from config import School, Teacher, Course, MRS

  MNH = Teacher(MRS, “Marissa”, “Neve”, “Harman”)
  BIO = Course(“Biology”, MNH)
  ST_SIMONS = School([BIO])

Oh what a nice tidy config you have there! Let’s ruin it!

  courses = [BIO]
  if str(today()) < “2023-04”:
    courses.pop(BIO)
  if today() > DIVORCE:
    for c in courses:
      if c == BIO:
        c.teacher.name = (“Marissa”, “Cox”)
        c.teacher.title = “Ms”
  # gibberish ad nauseam

I suppose it’s possible to write nonsense code in any language including YAML, so I don’t know if this is a very good point or not. To put it diplomatically though: your cadre of YAML editors, should they be moved over to using Python, are probably the ones who need the most help writing clear code.

[ Parent | on HN ]

Re:XML is better than YAML by lodovic on Thursday September 21, 2023 @01:12AM (#37593450)

I'm not convinced that trading a whitespace sensitive DSL for a whitespace sensitive dynamic scripting language will solve the issue.

[ Parent | on HN ]

Re:XML is better than YAML by TeMPOraL on Thursday September 21, 2023 @02:50AM (#37594039)

I think whitespace sensitivity was not the point of the exercise.

But on that topic, I feel whitespace sensitivity is a bad idea even for generic-audience configs. People learn how to use parentheses in primary school. Explicit grouping and nesting isn't black magic.

[ Parent | on HN ]

Re:XML is better than YAML by Smaug123 on Thursday September 21, 2023 @05:44AM (#37595380)

In general I am sympathetic to whitespace - I find the argument "whitespace insensitivity means the code now contains two conflicting sources of truth: whitespace which the programmer uses, and braces which are the only one that matters because that's what the computer uses" to be compelling.

But the whitespace sensitivity of YAML is particularly bad because of e.g. Helm. Templating a whitespace sensitive language with string interpolation is such a terrible idea.

[ Parent | on HN ]

Re:XML is better than YAML by diarrhea on Thursday September 21, 2023 @03:11AM (#37594177)

Took the words out of my mouth.

This is exactly what I fear will happen. If you look at the YAML some people produce and extrapolate that to one of the most dynamic languages available, it is going to get ugly.

Programming languages for config are better, and I will throw up if I ever have to see “list comprehensions” and null checks in Terraform ever again, but it requires people who can code. If you simply replace YAML with Python and that’s folks’ first time using a normal language, it won’t work. Hence I’m happy to stay with YAML mostly, in such a scenario.

[ Parent | on HN ]

Re:XML is better than YAML by dvdkon on Thursday September 21, 2023 @04:12AM (#37594659)

Then again, the YAML of Ansible or various CI platforms basically is code. People who already successfully write that will do well enough in Python. (Not that YAML isn't used in plenty of non-code usecases.)

[ Parent | on HN ]

Re:XML is better than YAML by diarrhea on Thursday September 21, 2023 @09:35AM (#37597402)

It is code, but without any of the aspects usually ascribed to code. Abstraction, tools like dependency injection (fancy term, but simple and highly important concept), more complex looping (not just `for each item do`; `for each item do, if item...` etc. are needed).

Unit tests?

Not to speak of tooling support. I can write a Python application with the strictest type settings and have mypy do a lot of heavy-lifting for me, before even running the app once. A bit like Rust. Check out the typestate pattern for what I am on about. It's invariants enforced in the type system, by the compiler. Impossible to misuse: your code simply won't compile. All of that is impossible to have if your types are strings only, with the odd bool and float inbetween.

I will accept that we cannot have ops people be at least medium-grade developers, which would be needed to apply these topics (I consider myself an in-between, leaning dev). That's simply infeasible. It's two different worlds. I will not accept the premise that these things aren't objectively better though! They're practically inachievable, sadly (or at least a decade away).

So no, in that advanced sense, YAML is not code. And if you can do YAML, yes you will get Python syntactically correct with a little practice. That is only 5% of the way though. Note I'm also not advertising for Enterprise Java-level of code... but more than "YAML but in Python".

[ Parent | on HN ]

Re:XML is better than YAML by XorNot on Thursday September 21, 2023 @08:24AM (#37596579)

I disagree strongly: configuration should not be code. Code should be code. Configuration should be static and simple.

It is not trivial to tell what code is doing, and as soon as your configuration is code then really you're developing a new application which implements another configuration language.

[ Parent | on HN ]

Re:XML is better than YAML by diarrhea on Thursday September 21, 2023 @09:31AM (#37597364)

Sure, if your infrastructure landscape is describable statically, that's how it should be done.

Most scenarios nowadays are _not_ like that anymore. There isn't 5 servers next door, there's 300 serverless whatevers half a globe away. Are you going to have 300 list entries, 230 of which nigh identical but 70 subtly different? Trivial in code, almost impossible to express statically.

[ Parent | on HN ]

Re:XML is better than YAML by XorNot on Thursday September 21, 2023 @06:29PM (#37605320)

What you're describing though is a configuration variability which would be expressable by a static tagging regime - still simple.

If your configuration is getting more complex then that though, again, it's not really configuration anymore - it's a management application which needs to be developed and treated like that. And why it's that complicated should be re-evaluated - i.e. how come this is "configuration" and not something the application detects for itself? Why is it being surfaced to the user (operator) at all?

[ Parent | on HN ]