41–50 of 107 posts
I'm still regularly surprised by Markdown. I have to rely on previews and occasionally still need to check the docs.
My bulleted lists often break and I can never remember the syntax for links.
It's ok to like WYSIWYG even if you're a hacker.
Am I the only one who finds YAML much harder to write than JSON or XML? It's not just the fact that I get the syntax for lists and maps confused all the damn time. The worst part is that I'm unable to use the keyboard shortcut for automatically formatting my document! I love that keyboard shortcut! I hate being without it! I'm certain it represents more than half of my key presses in other languages! I type a few cha…
If it doesn't then I'm using the wrong editor.
I wonder why IDE-enforced markup-schemas haven't caught on. Like a static type system for your markup (i.e. Kubernetes could declare your "types" and your editor could ensure the config fits them). VSCode has something along these lines for JSON - at least on its own settings configuration - but somehow the approach hasn't become prevalent. Are we lacking a standard? Motivation?
K8s will accept a cpu value of 0.1, but the plugin marks it as an error, it wants the millicpu version 100m instead.
I wonder why IDE-enforced markup-schemas haven't caught on. Like a static type system for your markup (i.e. Kubernetes could declare your "types" and your editor could ensure the config fits them). VSCode has something along these lines for JSON - at least on its own settings configuration - but somehow the approach hasn't become prevalent. Are we lacking a standard? Motivation?
I think perhaps protobufs (specifically text format protos) are a potentially really nice solution, since you get to leverage the protobuf type system. Unfortunately the support for them is a bit lacking.... (afaik, no formal spec - there’s a canonical implementation in C++; no editor support for things like linting and completions).
The author mentions a desire to be able to teach a data format to people in the way someone can comprehend HTML or Markdown easily. But the formats have different goals.
The goal of HTML and Markdown are to provide a way to encode document formatting in a simple text syntax. There's not one single correct way to format a document intended for presentation to and consumption by humans. Pretty much anything goes, HTML and Markdown just provide some decoration.
But the purpose of YAML (and JSON and TOML) is to provide a way to represent strictly defined data structures for consumption by a computer. The reason YAML is frustrating is because you can't fudge the result; you can't be sloppy or inexact; YAML operates at the boundary between the human and the computer program, and just like any HCI, it's going to be frustrating and error-prone.
Now, would it be possible to come up with a better format than YAML or JSON or TOML that does the same thing? Maybe. But the facts that tools exist to search and manipulate these formats and that we'll probably still be using them in 2030 isn't evidence that they are bad. The fact that yq can exist and is useful is a point in favor of YAML, imo. If simple tools can be written to do useful things with a data format, that makes the format more useful.
TOML remains severely underrated, for some reason. It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments! If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when…
However, a benefit to TOML's weakness with complex data is it encourages developers to keep things simple.
I hate this sort of article. Lots of griping about the problems with YAML, but no solutions. What does the author think is better? XML doesn't map to the same data structures as YAML, JSON, and TOML, so it's not really a comparable beast. The author mentions a desire to be able to teach a data format to people in the way someone can comprehend HTML or Markdown easily. But the formats have different goals. The goal of…
If you treat XML attributes as @-prefixed variables in the set of json nodes and visa-versa, they're fully compatible.
Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file. I remember being pretty…
It's not a panacea, but it can help avoid those long debugging sessions.
[0]: https://json-schema-everywhere.github.io/yaml
[1]: https://marketplace.visualstudio.com/items?itemName=redhat.v...
After working with YAML and JSON (and XML and INI and CSV and so on), it seems like a) JSON is equivalent and simpler for basic structures, b) JSON + jq or a language library is better than YAML's complex syntax (like not being able to merge lists[1]), and c) YAML has too many ways to express the same thing. Writing YAML is basically trial and error. [1] https://stackoverflow.com/q/24090177/96588