Next time the author would like to write an article like that, it’s better that they offer a new standard that is as flexible while also doing the work YAML is doing today
KDL? https://kdl.dev/
That's a Lot of YAML
31–40 of 78 posts
Re: That's a Lot of YAML
#32Earlier quoted context omitted.
EDN? Probably too flexible from some perspectives. No surprise Norways though.
That’s the problem people IMO don’t understand - flexibility is one of many requirements; simplicity and ecosystem around are two more. Hating YAML is same as being childish - yo using like something but can’t come up with anything better. Worse than YAML can be only complaining about YAML. Hating YAML is a cliche. Its much easier to come up with jokes like this website than to change the ecosystem for better. And I…
> That’s the problem people IMO don’t understand - flexibility is one of many requirements; simplicity and ecosystem around are two more.
Biggest issue IMO is moving goal posts and people wanting one format to do it all. Different formats are good for different things, except YAML, which again tries to do it all yet excels at nothing.
Re: That's a Lot of YAML
#33There is no problem with YAML, just like there was no problem with XML at all. The problem is with the software devs who use it for the wrong thing. I just wonder why JSON doesn't get all the hate, while it is a terrible format also: it is not streamable (YAML is), it doesn't have comments... and non-standard workarounds are used for these features. Norway better than YAML, in my opinion.
YAML is (or at least, is declared by its maintainers to be) a superset of JSON, making any JSON document also a valid YAML document. So surely if YAML is streamable, JSON must be too? Or are the YAML maintainers incorrect?
Yaml streams are just yaml docs separated by "---" withing a single file.
The json spec just doesnt do anything like that but jsonl does.
Re: That's a Lot of YAML
#34- "something broke" is way better than stack traces with line numbers That sums it up. Its the same since the days of XML. Someone decides to make something configurable externally and then everything gets put in there for convenience. Now we are programming in XML/YAML without even a stack trace (or a debugger, or call hierarchy, or type checking or ... )
Pretty sure strictyaml tells you which line was faulty.
Re: That's a Lot of YAML
#35There is no problem with YAML, just like there was no problem with XML at all. The problem is with the software devs who use it for the wrong thing. I just wonder why JSON doesn't get all the hate, while it is a terrible format also: it is not streamable (YAML is), it doesn't have comments... and non-standard workarounds are used for these features. Norway better than YAML, in my opinion.
There numerous problems with YAML. It is underdefined, ambiguous, fragile, and is just impossible to write a portable parser for. JSON is naive, lacks almost everything. But is supereasy to parse and read. As funny as it sounds, XML is overspecified. Parsing is possible and predictable but supporting the full standard (all of them) is so much work that nobody does it anyway. So, given the choice above, i'd go for nai…
There is a subset of yaml which is like 99.9% of all yaml code that is fine.
And then you have whatever the hell OpenAPI uses.
Re: That's a Lot of YAML
#36chuckle Well most of that is due to 1.1 which has been deprecated god knows for how long. 1.2 does not have the 'Norway' problem any more. Tooting my own horn, this is how a modern YAML library looks like nowadays: https://github.com/pantoniou/libfyaml
I read that as libfuckyaml
Re: That's a Lot of YAML
#37YAML is fine. TOML is a lot worse. Nobody anywhere needed more INI files.
> YAML is fine. TOML is a lot worse.
Care to elaborate? We are using TOML for config files and just do fine.
Re: That's a Lot of YAML
#38There is no problem with YAML, just like there was no problem with XML at all. The problem is with the software devs who use it for the wrong thing. I just wonder why JSON doesn't get all the hate, while it is a terrible format also: it is not streamable (YAML is), it doesn't have comments... and non-standard workarounds are used for these features. Norway better than YAML, in my opinion.
YAML is (or at least, is declared by its maintainers to be) a superset of JSON, making any JSON document also a valid YAML document. So surely if YAML is streamable, JSON must be too? Or are the YAML maintainers incorrect?
I wrote a C++ library at work that, among other things, serializes/deserializes to JSON, CBOR and BSON. I don't get that point.
The first two formats I've implemented as fully streaming, the serializers emit into an output iterator one character/byte at a time and the deserializers only need to hold one value at a time (mostly for strings, and not even for CBOR's byte arrays, which are streamed). BSON requires full document instantiation because of byte offsets and is genuinely anti-streaming in its design.
I happen to have implemented a serializer for YAML, fully streaming, mostly as a compact-ish human-readable debug data representation. I can scarcely think of fates worse than having to write a spec-compliant YAML parser.
Re: That's a Lot of YAML
#39It’s because ppl are not using it correctly, it was designed for configs and now it’s being used as a programming language… a language without types and debugger. It’s frustrating devs because they find the issue at the deployment time, not the compile time.
Personally I did never pick the YAML as a first format for the configs, only my ruby friends did that.