4 ms·

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 socia

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.

lodovic 3y ago
I'm not convinced that trading a whitespace sensitive DSL for a whitespace sensitive dynamic scripting language will solve the issue.
- TeMPOraL 3y ago
  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.
  - Smaug123 3y ago
    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.
diarrhea 3y ago
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.
- dvdkon 3y ago
  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.)
  - diarrhea 3y ago
    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".
- 3y ago

lodovic 3y ago

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

TeMPOraL 3y ago
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.
- Smaug123 3y ago
  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.

diarrhea 3y ago

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.

dvdkon 3y ago
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.)
- diarrhea 3y ago
  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".
3y ago