Earlier quoted context omitted.
JSON5 is also a great alternative: https://json5.org/ Supports comments, trailing commas, single quotes, multi-line strings, and more number formats.
I really wished json5 would support optional commas as well. If you have a new line, no comma needed. So you can do [ 1 2 3 ] New lines used by humans, computers should do a good job as well.
YAML: probably not so great after all (2017)
361–370 of 412 posts
Re: YAML: probably not so great after all (2017)
#362Re: YAML: probably not so great after all (2017)
#363One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usa…
"JSON" became popular in the 90s. They were http requests which returned javascript which you would simply eval(). No need to write or import a parser, and it is the same syntax as the language you're using, because it is the same language. In technology many things become popular not because how good (or bad) things are, but how easy to use something is.
Re: YAML: probably not so great after all (2017)
#364Earlier quoted context omitted.
> There's no language that I'm aware of that can natively generate PHP syntax This is a solid argument against using PHP (or any such language) as a cross-language data interchange format. There are others :) And I totally agree you want a language independent format for anything you might have to feed across an ecosystem of tools. For a PHP-system generating/altering its own config files... PHP's `var_export` genera…
You don't know when you'll need to generate or parse your config files with something that either can't read, write or execute your language. Django's settings.py sucks. I've used Django since the 0.9 days. It's extremely impractical and needs to be worked around constantly.
And you won't have to generate your config files (parsing, maaaaaybe), because those needs are covered by the fact that the files are programs. They are _already_ generating a configuration.
Re: YAML: probably not so great after all (2017)
#365 [1] https://github.com/servo/webrender/
[2] https://github.com/ron-rs/ronRe: YAML: probably not so great after all (2017)
#366Earlier quoted context omitted.
If you're going to do this kind of thing why would you not add a standard date format
Just use a string and ISO 8601? “2018-03-25”
Re: YAML: probably not so great after all (2017)
#367also what was wrong with ini files?
Re: YAML: probably not so great after all (2017)
#368For config formats I'm finding HCL[1] to be nice for my use cases. It has comments, no requirement for double quoted identifiers, and is actually simple. The main issue was the only implementation is in Go, so I had to write a port to C++. [1] https://github.com/hashicorp/hcl
I've only got one FOSS project using HCL but I think of its' bundled HCL config file is an attractive part of its UX: https://github.com/LukeB42/psyrcd
Re: YAML: probably not so great after all (2017)
#369Earlier quoted context omitted.
Thank you for StrictYAML I might just use it. It does look like a nice hair cut. You might wish to give Ingy a ring. He has been itching to move forward on a reduced/secure YAML subset. That said, StrictYAML seems to be a tad bit more of a hair cut than I'd imagine. I'd keep nodes/anchors, since I think a graph storage model is underrated; I think that data processing techniques just haven't caught up with graph stru…
Great to have you here elaborating on various design choices. Are you perhaps familiar with OGDL [1] and what's your opinion? [1] http://ogdl.org/spec
Other use cases such as dumping any in-memory data structure from memory, perhaps out of a sense that we needed full completeness, actually didn't have any end-user usability testing. Round-tripping data seems in retrospect to be a diversion from the primary value that YAML provided.
Re: YAML: probably not so great after all (2017)
#370Earlier quoted context omitted.
Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".
Is there a yaml parser that preserves comments and a writer that manages to write them back though?