Yet another “brilliant” scheme from a cryptobro. Naturally this caused a gold-rush for scammers who outsourced random people via the gig economy to open PRs for this yml file (example)
Yet another “brilliant” scheme from a cryptobro. Naturally this caused a gold-rush for scammers who outsourced random people via the gig economy to open PRs for this yml file (example)
The easy red flag here is YAML. It’s a hideous, overly-complex format for anything so of course a scam would choose it.
That’s a patently ridiculous statement
Have you read the spec? It’s a total mess
I have read the 1.2 spec (I’m trying to make a round trip parser for JS, and I do maintainance on a fork of the rumel yaml python package). I actually think its very well thought out, with things I hadn’t considered like future extensibility, streaming applications, and data structures in many languages.
The diagrams, color coding, and less-formailty of the spec was much appreciated, compared to something like the ECMA Script spec, which reads like a math textbook had a child with a legal document.
I’m not saying YAML is perfect; round trip (the thing I’m working on) is nearly impossible because it wasn’t a design goal. It has a few too many features, I’ve never seen a declaration in the wild, but it does a good job at accomplishing the creators goals, and the additional features basically only slow down parser-implementers like me. I often pick it because of the tag support, which I’ve struggled to find an equivalent for in other serialization languages. I use anchors in recursive data structures, and complex keys for serializing complex data structures (not human readable). The “document end” marker has been nice when I’m worried about detecting partial-writes. And the merge key is nice for config files.
The application/perspective matters. Yaml might be bad for you but its not bad for everyone.
Even if anchors are pretty novel… I’ve watched myself & others fail for things that seem like they should be simple like scalars, quoting, & indentation rules all for being confusing (while failing to understand how/why the tab character isn’t supported).
Brief history of YAML:
YAML is generally good if it’s used for what it was originally designed for (relatively short data files, e.g. configuration data). Problem is, people use it for so much more. (My personal favourite pain example: i18n stuff in Ruby on Rails. YAML language files work for small apps, but when the app grows, so does the pain.)
Ansible is using YAML and it’s orders more readable than any other config engine, like puppet or cfengine.
What? I love having 20 ambiguous ways to express the same data with weird and unexpected conversion rules. JSON is so much worse - if data types are explicit and obvious, how can I properly express my feelings when writing a config file?
And what would your ideal, legible, general-purpose data markup language be? XML?
Yaml Ain’t Markup Language: am i a joke to you
(JSON for data, TOML for configuration)
I’ve used both YAML and a TOML-adjacent INI format for Ansible. While I wouldn’t use YAML for massive data serialization (because significant whitespaces are fucking stupid), it’s much better suited for manual data entry compared to most options, including TOML, when nested data structures are required.
And if YAML’s structure is too complicated, that’s honestly a skill issue.
Not that YAML’s structure is too complicated, but its syntax is too flexible. All the shit about being whitespace sensitive yet with whitespace errors leading to a syntactically valid YAML document. TOML’s syntax is rigid which makes it unsuitable for expressing complex nested data structures, which is good because that’s not what you should use TOML for. Ultimately the dependence on a highly flexible baseline language like YAML to create complex DSLs is a failure on the developers’ part, and the entire configuration system should be reworked.
Depends on the use case but XML is good for markup—especially if you need extensibility.
For config, Nickel & Dhall take the cake for being typed & having LSPs so the configuration writer can get immediate feedback about possible options without requiring the manual—with configuration readers not needing to mess around with marshalling their types. Both these configuration languages let you import files & write little loops to make your config more DRY & makes maintaining large files (like say Kubernetes) easier.
XML is great if the (de-)serialization is already implemented. Otherwise traversing the document is a massive pain.
True. Something like XPath can really help & there are use cases where that is more concise but requires loading XPath into your head like Regex (which tends to get unloaded). The extensibility shines tho as seen by XMPP continuing to this day with very good backwards compatibility with 2 decades of updates since everything in an extension to the base.
RON (Rusty Object Notation). Its like JSON but better.
I see you get downvoted a lot. But as a norwegian that repeatedly have run into the norwegian problem when trying to use some program… i see you.
What’s the weather like in
False?