31–40 of 69 posts
foo.password = xxx
bar.password = yyy
wifi.ssid = fooAbout 20 or so years ago, I have come across a configuration pattern that could be arguably called "Level 0". It was configuration by file existence. The file itself would be typically empty. So no parsing, syntax, or schema involved. For example, if the file /opt/foo/foo.txt exists, the software does one thing but if it is missing the software does another thing. So effectively, the existence of the file serves as a…
I agree with this (even though, In practice I usually just use JSON or YAML) - it avoids some of the pitfalls of both JSON and YAML - has comments, lacks ambiguity. The main annoyances are textContent (is whitespace important?), attributes vs children, verbosity of closing tags, etc.
For example, can "total programming languages" include: "for i in range(10000000000000): do_something()"?
If so, your config file can still hang - even though it provably terminates.
I’d argue Terraform/HCL is quite popular as a Level 4 configuration language. My biggest issue with it is that once things get sufficiently complex, you wish you were using a Level 5 language. In fact, it’s hard to see where a Level 4 language perfectly fits. After you’ve surpassed the abilities of JSON or YAML (and you don’t opt for slapping on a templating engine like Helm does), it feels like jumping straight to L…
Level 4 is also far more declarative by nature, you cannot fully compute stuff so a lot is abstracted away declaratively. This also leads to simpler code since you're less encouraged to get into the weeds of instantiation and rather just declare what you'd like.
Overall it's about forcing simplicity by not allowing the scope of possibilities to explode. Certainly there are cases where you can't represent problems cleanly, but I think that tradeoff is worth it because of lowered complexity.
Another benefit of level 4 is that it's easier for your code can stay the same while changing the underlying system you're configuring. Since there's a driver layer between the level 4 configuration and the system which can (ideally) be swapped out.
It’s made the page before and proposes that these forms are cyclic.
I’d argue Terraform/HCL is quite popular as a Level 4 configuration language. My biggest issue with it is that once things get sufficiently complex, you wish you were using a Level 5 language. In fact, it’s hard to see where a Level 4 language perfectly fits. After you’ve surpassed the abilities of JSON or YAML (and you don’t opt for slapping on a templating engine like Helm does), it feels like jumping straight to L…
https://developer.hashicorp.com/terraform/language/syntax/js...
Earlier quoted context omitted.
Level 4 is turing complete. There's two parts that I was talking about. Things that are not quite that and the fact that configuration can have that capability in a fairly useless context. When I'm dealing with personal things or stuff that few people use I will often make the configuration just something I eval/source. So it in theory has the same functionality as the underlying programming language, but in practice…
Level 4 / total programming languages are not turing complete. Because you can't simulate every turing machine in them, only some subset that provably halts. (And because the halting problem is undecidable, there will always be some turing machines that actually do halt but still can't be simulated because the compiler can't prove it)
It didn't originally use the obscure formal idea of a "total" language
About 20 or so years ago, I have come across a configuration pattern that could be arguably called "Level 0". It was configuration by file existence. The file itself would be typically empty. So no parsing, syntax, or schema involved. For example, if the file /opt/foo/foo.txt exists, the software does one thing but if it is missing the software does another thing. So effectively, the existence of the file serves as a…