[dead]
YAML? That's Norway Problem
21–30 of 46 posts
Re: YAML? That's Norway Problem
#22Reminds me of some enum at my current employer, where all the US states have 2 letter codes, except Idaho is spelled out fully.
Re: YAML? That's Norway Problem
#23Somehow my brain finds YAML hard to parse. JSON is easy but ugly. Lately I’ve just been using Python code in a module to initialize config settings. Initially it was just a lazy way to get started, but having the flexibility of an actual language is great when things evolve over time.
That was the initial intended use case for Python to be a configuration language.
Re: YAML? That's Norway Problem
#24Somehow my brain finds YAML hard to parse. JSON is easy but ugly. Lately I’ve just been using Python code in a module to initialize config settings. Initially it was just a lazy way to get started, but having the flexibility of an actual language is great when things evolve over time.
That was the initial intended use case for Python to be a configuration language.
Really? I thought that was more the case for Lua. Which by the way is more happiness per line of code than most other languages :-)
Re: YAML? That's Norway Problem
#25YAML is the worst format. You are literally one missing tab away from breaking your entire configuration file. Yet the industry keeps pushing it for the sake of “simplicity” - for small configurations sure, it’s fine, but many hundred lines of config entries? Good luck fixing it, if something goes wrong. I still can’t get why software engineers suddenly started to hate XML.
>You are literally one missing tab away from breaking your entire configuration file.
Isn't this true for Python, too?
Re: YAML? That's Norway Problem
#26I find JSON better for serialization/deserialization. It's a bit tedious to write by hand but who writes JSON by hand?
Re: YAML? That's Norway Problem
#27YAML is the worst format. You are literally one missing tab away from breaking your entire configuration file. Yet the industry keeps pushing it for the sake of “simplicity” - for small configurations sure, it’s fine, but many hundred lines of config entries? Good luck fixing it, if something goes wrong. I still can’t get why software engineers suddenly started to hate XML.
>You are literally one missing tab away from breaking your entire configuration file. Isn't this true for Python, too?
It is, yes. And unlike YAML, there's no official way to use a syntax that doesn't use whitespace to define scope.
Python's whitespace-defines-scope syntax is the reason I won't use it unless I have no other choice. If it weren't for that -IMO- extremely poor design choice, I'd consider it to be a decent language. [0]
[0] Yes, some people think this feature of Python is fine. I'm not one of them. Whether or not you think this feature is fine is a matter of taste.
Re: YAML? That's Norway Problem
#28I find JSON better for serialization/deserialization. It's a bit tedious to write by hand but who writes JSON by hand?
Write json5, which gives you most of the brevity of yaml without the terrible ideas
I find even plain json easier to write than yaml. Especially when you factor in the scope of mistakes. Tiny mistakes can completely break the structure of a yaml document in ways that are still valid yaml. With json I'll catch that because auto-indenting will follow the actual structure
Re: YAML? That's Norway Problem
#29YAML is the worst format. You are literally one missing tab away from breaking your entire configuration file. Yet the industry keeps pushing it for the sake of “simplicity” - for small configurations sure, it’s fine, but many hundred lines of config entries? Good luck fixing it, if something goes wrong. I still can’t get why software engineers suddenly started to hate XML.
> You are literally one missing tab away from breaking your entire configuration file.
In JSON, you’re one curly brace away from breaking your entire configuration file. How is that different?
Re: YAML? That's Norway Problem
#30Earlier quoted context omitted.
It wouldn't need to be if closing tags were allowed to be unnamed. For most cases, we can tell the closing tags easily enough for simpler files: MAML minimal readable 1 Anton Medvedev JSON 2001 MAML 2025 This is a multiline raw strings. Keeps formatting as-is.
But if closing tags are allowed to be unnamed, you are still one misplaced away from unrecognizably maiming the entire hierarchical structure, just like one incorrect indent can do in YAML. Ultimately, what matters is the editing mode and not the data format. Good syntax highlighting and autocompletion goes a long way towards safely editing structured text, regardless of on-disk format.
You need to misplace a in a way that still produces a valid xml document. Just forgetting one or adding an extra one will throw an error.