331–340 of 457 posts
Templating YAML is even worse. Templating is an ad-hoc abstraction, and very easy to run into issues. A minimal JavaScript runtime with JSON would be much better, JSON is JavaScript Object Notation after all.
From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?
i've collaborated on ytt (https://get-ytt.io) - yaml templating tool. it works directly with yaml structure to bind templating directives. for example setting a value is associated with a specific yaml node so that you dont have to do any manual indenting etc. like you would with plain text templating. defining functions that return yaml structures becomes very easy as well. common problems such as improperly escaped values are gone.
i'm also experimenting with a "strict" mode [1] that raises error for questionable yaml features, for example, using NO to mean false.
i think that yaml is here to stay (at least for some time) and it's worth investing in making tools that make dealing with yaml and its common uses (templating) easier.
From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?
At my old place we developed a small tool that wraps CloudFormation with a templating language (jinja2). This was actually great as it CloudFormation is extremely verbose and often unnecessarily complex. Templating it out and adding custom functions to jinja2 made the cfn templates much easier to understand. I think it all depends. Most of the time I would agree that you shouldn't template yaml, but sometimes, it's t…
https://github.com/cloudtools/troposphere
The basic type checking done was quite helpful, and avoided some of the dumb errors that we had run into when we attempted to do everything by hand.
fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML). Boxes to check: 1. Self describing format 2. SAX-style parser available to C++ 3. Easy for users to understand and ad-hoc parse using command-line tools 4. No document closing necessary, so appending is trivial YAML looks pretty good: - cmd: git checkout file.txt when: 1565133286 pwd: /home…
TOML?
[1] https://github.com/toml-lang/toml/issues/356
[2] https://github.com/toml-lang/toml#user-content-array-of-tabl...
Earlier quoted context omitted.
Not sure if I’m familiar with the term “design defense”. Can you explain? Stumbled into the idea. Basically just brute forced it. Tried thousands of things, built a huge database of languages, and tried to keep it simple.
I take the idea of “design defense” from Pyramid (Python Web Framework) [0], and have incorporated it into documentation on my projects. Basically, it’s a narrative discussion of how this solution came to be, the trade offs involved, and perhaps its relationships with prior art. [0] https://docs.pylonsproject.org/projects/pyramid/en/1.10-bran...
But in other languages with notoriously irresponsible coders (JS, PHP) I bet to see even more of these problems.
(I coded in all of them)
Earlier quoted context omitted.
Can't recommend TOML enough. I use it for everything. Super simple and easy to edit. It fulfills all of the requirements. There are several available C++ TOML parsers, including one from Boost.
Do you ever have the limitation that arrays must be of a single type come up as an issue?
YAML is bad. It's like markdown, there are too many parsers behave differently. Unlike markdown just for reading, it is used in configurations for critical systems. JSON is much better, it IS readable and writable, people using package.json all the time without problems. Templating YAML is even worse. Templating is an ad-hoc abstraction, and very easy to run into issues. A minimal JavaScript runtime with JSON would b…
Earlier quoted context omitted.
TOML?
TOML would be great, if not for an annoying obscure detail in the specification that makes it hard to use for my typical use cases (scientific computation) [1]. Moreover, I find quite unintuitive how you are supposed to specify array of tables [2]: this kind of is much easier in JSON (which is the format I am currently using, although it is far from perfect). [1] https://github.com/toml-lang/toml/issues/356 [2] https…
Personally I really like the array of tables syntax. It is a little unintuitive but it's not difficult to remember. It's useful for fulfilling the OP's "No document closing necessary, so appending is trivial" requirement.
And if you don't want to use it, you can always use inline tables in an array, just like JSON.
tl;dr: Another alternative to YAML (among many great others), this one designed and developed by me: https://eno-lang.org/ I've been doing a lot of research and development on language design for file-based content (e.g. for static site generators). I've found that YAML - although established as the go-to format for statically generated blogs, etc. - was never designed for these things as it by its nature does not su…
iterations: 100000
evaluated: Fri Jul 06 2018 09:46:48 GMT+0200 (Central European Summer Time)