Why?

What was the reason to create alternative JSON with crappy syntax? Are the normies behind this?

Attached: yaml[1].png (792x288, 26K)

Other urls found in this thread:

hackernoon.com/consistently-bad-parsing-of-yaml-ae23eb3676a1
twitter.com/AnonBabble

Can you put comments in yaml?
It's more like an alternate to INI with crappy syntax but you can do hierarchies.

>Are the normies behind this?
More likely webdevs.

How is YAML's syntax crappy?

Although, honestly, it's basically taken everyone 2 decades to reinvent the INI file format which was perfectly good in the first place.

Legit question: is INI actually better than YAML/JSON for shit like settings? It's far easier to read with no weird shit like meaningful whitespace, and its minimal to discourage devs being idiots and overengineering shit

[blah_blah]
blah=blah

is easy as fuck to read, write and understand.

>is INI actually better than YAML/JSON
yes if it doesn't make sense to have nested data structures.
If you need something more complex than just key=value then use json.

Ehh, JSON can be pretty ugly to read so a better JSON is, in theory, a good idea.

At least we're not stuck with XML and CSV anymore. Dealing with that shit was a real fucking headache.

I use it all the time for configuration files.
Much nicer syntax to hand edit than JSON.

yes, # denotes a comment

Easier to write than JSON. JSON has a lot of fluff that makes writing it annoying by hand, yaml is more natural.

Json is xml without overhead. Yaml is json with even less overhead.

Besides you can embed xml and json into yaml and you can have anchors, which jsonschema has but json itself doesn't.

YAML is bloated and over-engineered as fuck, though. YAML is literally a superset of JSON.

It's a shame there isn't a popular universal settings file format.

>It's far easier to read with no weird shit like meaningful whitespace

I agree that meaningful white space can be pretty annoying sometimes.
But it does force indentation which makes it much easier to read.

In many text editors it also allows you to collapse/expand sections for even better readability, I don't think you can do that with INI.

And as mentioned YAML isn't limited to single values, you can also define (nested) arrays and objects.

Wrong: YAML is minimalist and sane. JSON on the other hand is literally JavaShit.

Try to write a parser for each one and then you will realize how stupid was your comment.

>YAML is bloated and over-engineered

Reminder that "bloated" and "over engineered" are code words for "I'm too lazy or/and too brainlet to read a Wiki page.

>force indentation which makes it much easier to read

Not if there's only one level - if anything, it makes it worse. And there's no reason text editors shouldn't be able to collapse ini files.

Again, what is really needed is a universal settings file format that doesn't have bloated functionality like nested arrays or circular reference etc. You don't need that shit for most uses, and if you do, chances are full-fat XML is a better option.

YAML isn't "minimalist" at all. Remember, YAML is literally a superset of JSON - a valid JSON document is literally valid YAML.

SGML > XML > YAML > JSON > INI in terms of complexity and functionality.

>CSV for config files
Is such a thing even possible?

sexps are the best

The advantages of using yaml are apparent e.g. when writing a docker compose file. You clearly see which service is configured with what, which volumes belong to it, where are the binds etc.. It really makes sense to use yaml sometimes, deal with it somehow and move on.

>Not if there's only one level - if anything, it makes it worse.

If there is only 1 level there would also not be any indentation silly.
And again forced, so no way to fuck it up.

>and if you do, chances are full-fat XML is a better option.

No way, XML is awful to read and manually edit.

Why not? You have 10 hosts, you define n number of columns each corresponding to a given setting. You parse headers or go with indexes.

CSV wasn't used for settings but for serialisation. Back in the day, CSV was the only universal serialisation format and, while it was "simple", it was a fucking nightmare in practice because there is no standard and everyone implemented it slightly differently

But you don't want to manually view and edit anything with nested-arrays and shit like that anyway.

Why not?
I do it all the time.

It's very easy with YAML, and it makes sense for the way my application needs to be configured.

>2005
lol. csv is like 50 years old and predates any standards.

Here's how you do hierarchies with INI files.

You have a fucking filesystem, use it - create directories and multiple files for different purposes.

Problem fucking solved. It's not like your 1000 line settings file is meaningfully "human-readable" anyway.

I still don't grasp how Microsoft want:
>CSV
>what does that stand for? comma separated values?
>AH! let's let's use semicolons instead and call it CSV anyways because fuck you that's why

Just call it SYLK.
Don't fuck up CSV just because your retarded name didn't catch on RRREEEEE

I have 4 or 5 levels in 50-200 line config files.

Splitting them up into tiny ass files would make them much harder to understand.

YAML CONSIDERED HARMFUL
JSON CONSIDERED HARMFUL
XML CONSIDERED HARMFUL
INI CONSIDERED HARMFUL
CSV CONSIDERED HARMFUL
TOML CONSIDERED DOUBLE HARMFUL
Really, you should just use

Harmful: SGML, XML, YAML
Less harmful: JSON, CSV, ndb(6), plain(UTF-8) text
t. suckless

>plain(UTF-8) text

What do you think all the other formats are written in?

Yes to:
XML - Enterprise-level serialization format
JSON - Nice serialization format for most things that aren't meant to be human-readable, especially with regards web dev
INI - ideal human-readable settings format, just avoid anything beyond the very basics that everyone uses.

Eh to:
YAML - Lots of added complexity in terms of parsing for the advantages it brings over JSON/INI
TOML - You really, really shouldn't need the shit it adds over INI, plus it's less popular than YAML.

Avoid:
SGML - Fundamentally broken
CSV - No single standard and not readable

CSV doesn't have to be UTF-8.
I bet that Japanese CSV uses Shift-JIS and 、 as separator.

>XML
needless bloat
>JSON
less bloated than XML but still needless bloat, also lacks any parallel to XML's attributes
>INI
lacks features in general and suffers from the same fate as CSV in that it's poorly defined

JSON is great, but YAML is better

No but CSV was already the joke format of the bunch.

How come these guys never caught on? They were literally made to solve this problem.

Attached: separators.png (748x289, 19K)

^^

INI and CSV are fundamentally different.

CSV is intended to be a serialization data format. It sucks at that because it isn't implemented consistently.

INI is a human-readable settings file format used by an individual app. It doesn't need to be interoperable. You shouldn't need a ton of features just to store settings - you want something simple, easy to parse and easy-to-read. INI is very good at that.

>Lots of added complexity in terms of parsing for the advantages it brings over JSON/INI

Why would you write your own parser?

Just use an existing parser or convert to JSON.
Plus it's really not that hard to write a YAML parser, simpler than XML in any case.

I agree, it's a shame.

I think they would have required dedicated keys on a keyboard, and their own glyphs to catch on.

Isn't it %?

These is no standard for INI. It'll bite ya. Use TOML or properties files.

>Plus it's really not that hard to write a YAML parser, simpler than XML in any case.
It is hard to parse all of YAML and to do it correctly. E.g.,
hackernoon.com/consistently-bad-parsing-of-yaml-ae23eb3676a1

You do have a point about INI and CSV being fundamentally different in their use case, but I'd still argue the inconsistent implementations are bad because it leads to the end user configuring the file having to make assumptions (does the program using this .ini file care about case? what escape character is used?).

Of course this can be solved via thorough documentation, but it's still a flaw.

Does yaml have references?
Also found it annoying that json didn't have a way to model cyclic structures.

I can see where you're coming from but on the other hand, ehhhh. INI files should have case-insensitive keys, but it outright doesn't matter in practice, and it uses standard C escape sequences.

Remember, the format is only ever read by a single parser and read/written by humans, which means almost all of its downsides can be shrugged off in practice.

Yes, it does.

I'm not convinced it's a good idea. YAML tries to do too much for its own good imo.

fugly, glad this never caught on

But because it's read and written by humans, any unspecified behavior and inconsistent implementations will inevitably lead to humans writing down mistakes that they won't detect until they run the program parsing it, after which it is entirely up to helpful error messages and documentations to help the user fix those mistakes. Ideally, a user should be able to open up any .ini file and know exactly what they can and can not do without checking for implementation-specific details.

Formats like JSON are good in that there's zero room for ambiguity and if developers want to do something bananas like supporting comments they explicitly have to let the user know that "hey, this is JSON, but it also supports
JS-style comments".

>I'm not convinced it's a good idea. YAML tries to do too much for its own good imo.

Then don't use those features.

Problem solved.

I don't think you quite grasp what's going on.

Those are 4 ASCII characters designed specifically to indicate a hierarchy.
For example: it's not really "^_" for unit separator, it's "␟".

They could have made it really nice looking in text editors, if it caught on.

there was no reason.

it's an over-complicated mess that no one can even seem to agreeably implement correctly.

>More likely webdevs.

ya, no. everyone is jumping on this shit.

docker-compose, ansible, etc. I can't think of any webdev thing that uses this syntax outside of pandoc markdown preprocessor thing.

you sure it's not ;?

Yeah, until you realise it makes YAML more complex and leads to more complex parsers, which leads to more bugs, less consistent output, security issues etc. Particularly the references stuff which leads to YAML bombs.

YAML both tries to be a universal markup language while being backwards compatible and lightweight. The reality is that nothing can be good at everything as it creates trade-offs. Having two simpler markup languages is a better idea.

So it's hipsters with meme technologies.

pretty much.

>bloat
>bloat
>lacks features

Attached: shork.jpg (850x839, 129K)

I'd rather see json5 at this point with some optional "this" syntax for fags who want to have possible circular reference bombs ala, xml or yaml.
or at least update json to allow for trailing fucking comma and C99 style comments; there, problem fucking solved.
deco seems cool too since it doesn't have delimiter collisions at all, which might make it easy to develop high performance parsers for it.

XML should have the caveat that there’s at most one namespace. Preferably none.

>not just using association lists
'((retard you))

Nah. XML parsers should generally have namespaces, schema validation, xpath and all the other usual features.

Just drop the libs and languages that can't handle XML.

I’m not really talking about the parsers, more my sanity and everyone else’s who’s going to maintain the thing.
Look up XBRL if you want an idea of the abuse I’m talking about.

Attached: image.jpg (699x499, 653K)

Why isn't there a popular file format that just has three basic types and some way of specifying a namespace? And then accept anything beginning with any basic ASCII symbol character that isn't reserved (reserve ,.[]=") as a comment.

Like...

key.value1 = "UTF-8 String\nUsual C escape sequences like \\n" #another comment
key.value2 = true !Specifies a Boolean
key.value3 = 10.445 //BigDecimal, it's 2018.

And maybe some cut down notation for this (like INI but whatever)?

[key]
value1 = ....

Surely this would deal with a ton of use cases and be incredible simple and unambiguous to read and parse? How often do you need all the YAML/TOML bullshit?

I don't really see the problem from your image & I don't feel like reading that standard.

Does it even rival ISDN for how bad it is? Are you telling me this would be better if they just combined it all into one namespace that cannot even be updated without some consortium dragging it along?

Anyhow, namespaces are just fine, same as having library imports in a program.

JSON and YAML were both first introduced/defined*/used around 2001 or so so they're roughly contemporaneous.

I think they're both reactions to the complexity of XML, but other than that don't have much to do with each other historically.

YAML is intentionally not a minimalist format. It's also intended to be used for configuration files, hence the support for comments and semantically significant indentation.

*I don't mean standardized. The history there seems a little more complex.