YAML: Probably not so great after all

> Still, totally fine for pretty much everything I’ve needed it for.

Try writing non-trivial multi-line bash snippets for Gitlab CI in yaml. These change your opinion very fast.

Never thought about that, but indeed there is no termination string. I guess the same is true for python

This is more of a tooling problem than a language problem. I haven't thought about Python whitespace in ages (i.e. since I switched to modern code editing tools).

There's a huge difference in desirability for white space significance depending on whether or not it is used for code or data storage. Because the best practice is to decompose your code in functions and classes, space significance isn't so much a problem in Python. YAML on the other hand, is a visually atrocious way to store tree-like/multi-layered data.

Yep, whitespace should be used to make things "pretty", and some kind of 'tidy' program should be able to do it automatically. Counting the spaces and/or tabs and/or not even knowing which one it is, really sucks. Some editors help a bit with that, but it still sucks.

The problem is that people use spaces and not TABs here.

The TABualator key was invented for this purpose, in the age of the typewriter, to make things visually stand out by grouping it in the same column of a table. So all the lines that belong together are listed with the same indent, (originally all items belonging in the same column being listed under the same heading).

Example

    user:
      given_name: something
      family_name: somenting

Using a somewhat randomly number of spaces is just silly, the two name lines is one hierarcical level below "user" so add one tab char to represent that fact. Then you can vary the visual representation in your editor to your liking.

json is created to make it easy for machines to parse, not humans. Leave it to the machines.

Actually: one of the reasons TABis misunderstood is that cheap typewriters didn't have adjustable tabulator positions, and when computers came along it was often implemented with fixed columns (typically every 8), so people think of TAB as 8 spaces, which often is not what you want.

One of the nice things with Python compared to, say C, is that what you see visually is what you get. I.e. if you use TAB and not spaces to indent lines or are very careful about how many spaces you put in, but then you lose the ability to quickly change the visual representation.

In C you actually use indentation when you write code to make it readable for humans, but the machine doesn't care, so there is a disconnect between the visual and how it is parsed.

You have to both use indentation add a lot of curly-braces to your code. In Pyhon you don't have this double-work.

May I suggest StrictYAML?

https://hitchdev.com/strictyaml/

> it seems like the holy grail to the config files dilemma is to just hard-code desired settings in the source code

That is…not remotely the holy grail. You’re really throwing out the baby with the bathwater on that one. User-configurable settings are important for many, many applications.

In the narrow case that you’re working on, say, a monorepo for closed-source code that only runs on your own servers, maybe in source code is fine provided there’s no host-level differences that would require a config file.

But for any other circumstance…yeah you need some type of configurability.

Why not both? You can write config-looking Kotlin code so that user won't even realize it's Kotlin. But type-safe and with auto-completion.

Something like

    server {
      port = 8080
      addr = "127.0.0.1"
      development = true
    }
    
    db {
      url = $DB_URL
      user = "app"
      password = include(".secrets/dbpass.txt")
    }

I wrote a "common-config" module for an internal python project, that works like this:

1. You hardcode settings in python using a multiline TOML string

2. Users may have multiple configs at the usual config folders

3. The configs override the hardcoded defaults wherever fields are present

4. Configs override each other in order of directories (when we are talking about xdg-directories) and within them in alphabetical order wherever fields are present

This allows you to have good defaults, override some fields at will and add something like 99-debug.toml that you can just rename to 99-debug.toml.invalid if you don't need it anymore. The module also provides an install/edit cli and functions for printing the final resulting config and which configs it read on the way to that final config. At some point I have to publish it.

If you need anything more than TOML because your use case is so crazy, then consider either writing a domain specific language or use a scripting language like lua, python, js, ...

Not sure if I would call hardcoded settings in the sourcecode configuration - they are just constants. The primary benefit of configuration is the ability of changing the behavior of software without having to rebuild, redeploy, redistribute or even restart. Either by the user or by the developer or sysadmin, depending on context.

I cannot agree to the statement "Everyone hates yaml".

If that was true, it wouldn't have been used as much as it is.

Inconsistent formatting is a worse mistake, because people actually do read whitespace as structure, even when you wish they wouldn't.

I wrote an not very peformant parser for X12 once, if you mean the medical data format.