4 ms·
At the end of the day we’re structuring syntax in a file within the constraints of some compiler or interpreter, which itself is implemented as structured text.
by structringtxt 4y ago
At the end of the day we’re structuring syntax in a file within the constraints of some compiler or interpreter, which itself is implemented as structured text.
Engineering is about keeping it simple. So I agree; we can avoid dozens of flavors of structured text (using up worker time to learn, compute cycles to use) and stick to general programming languages rather than prove how clever we can be by creating yet another tokenizer, parser, writer with some hand wavy, tangential connection to mathematical concepts.
- mhsred5 4y agoThe problem with using a general programming language for configuration is you end up needing to use that config in different places, in different contexts, and from different languages. So, you have to marshall out and marshall in that structure to some intermediate format. You want it to be easy for humans to edit and grok, so you find a way to represent the core parts you care about as text and cordone off the general programming language to another area. You're successful and the number of use cases you cover grows, so the size of that config grows. And before you know it, you've invented YAML. Whereas, if you use Cue instead of YAML it looks pretty similar - in fact some large subset of it will be parsed correctly by a YAML parser. But the difference is with Cue you can: 1. Validate the structures in your config 2. Deduplicate by referencing other values in your config (something you can't do in JSON/YAML). 3. Use language built-ins to reduce boiler plate and repetitive text.