Object graphs are the answer to the endless iteration on the right config format:
http://codesolvent.com/config-node/
it is however difficult to pull off and requires productization, in other words not low-level tooling in a text file.
YAML: probably not so great after all (2017)
41–50 of 412 posts
Re: YAML: probably not so great after all (2017)
#42Semirandom question: what's the proper file extension for a YAML file? I've done informal polls on it and every time it's an even split between .yaml and .yml
There are plenty of file formats that have multiple extensions in common use. I can think of a few off the top of my head:
- .jpg / .jpeg
- .tif / .tiff
- .htm / .html
- .cpp / .cxx
It's frustrating at times, but not all file formats have One True Extension.
Re: YAML: probably not so great after all (2017)
#43I never understood what it is that people like about YAML. I keep configuration in EDN, which avoids all of the problems described in the article and has other advantages, too.
EDN is fantastic. It wasn't super portable last I looked though.
There is reasonably good library support: https://github.com/edn-format/edn/wiki/Implementations
Re: YAML: probably not so great after all (2017)
#44I think this is a problem of trying to serve all use cases at once. I mean, if you're making a data exchange format, do you really need it to be able to execute arbitrary code? Isn't that inviting trouble? It's like building a bank vault and then cutting a large hole in it and putting a plywood door on it - just in case somebody would want to convert it to a restaurant later. Maybe it would be better not to serve that particular use case at all?
Re: YAML: probably not so great after all (2017)
#45With YAML I can never remember what's an object versus a list, string, or number, nor am I ever able to add new stuff to a YAML file and get it to parse correctly without first looking up the spec. And it's impossible to see where large objects start and end. In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trail…
You use JavaScript a lot more than python, right? Intuitive usually means "close to what I'm used to".
Python objects and JSON are practically identical.
Re: YAML: probably not so great after all (2017)
#46With YAML I can never remember what's an object versus a list, string, or number, nor am I ever able to add new stuff to a YAML file and get it to parse correctly without first looking up the spec. And it's impossible to see where large objects start and end. In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trail…
https://json5.org/
[flagged]
Re: YAML: probably not so great after all (2017)
#47With YAML I can never remember what's an object versus a list, string, or number, nor am I ever able to add new stuff to a YAML file and get it to parse correctly without first looking up the spec. And it's impossible to see where large objects start and end. In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trail…
> In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trailing comma. I'd expand the list of quirks... JSON lacks comments (both line-level and block level). Fine for data transport but super super bad for configuration files.
This hits home. Every time I've ever had to make the decision I've chosen yaml, for exactly this reason. Funny how the seemingly small things can be absolute show stoppers when it comes to making decisions in production.
Re: YAML: probably not so great after all (2017)
#48Every time this comes up, I don't understand how https://json5.org isn't superior to YAML in every way.
If there was some deficiency with JSON5, just simply use JSON with comments. It's that simple.
JSON is one of the best things to ever come out of the CS disciplines.
For those that whine about comments in JSON, Douglas Crockford, the creator of JSON, himself said to do it.
>Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
Re: YAML: probably not so great after all (2017)
#49What about Toml , I like it.
Re: YAML: probably not so great after all (2017)
#50Object graphs are the answer to the endless iteration on the right config format: http://codesolvent.com/config-node/ it is however difficult to pull off and requires productization, in other words not low-level tooling in a text file.
That link is pretty terse. I have no idea what "object graphs" are in this context nor how they solve the "endless iteration on the right config format" problem. Moreover, churn on config file formats is probably the least of my dev problems.