I will die on the hill that XML is a superior config format and people are just afraid of it cause they see the advanced features (that you don’t need to use) and think it’s too complicated.
I’d have a much easier time with XML if I could feed it a json schema or something similar so my editor knows the format it should be in.
Like an XSD file?
This looks exactly like what I am looking for. Thank you!
Then maybe you should go ahead and write a brutally messed up but somehow ubiquitous scripting language that just somehow has its object instanciations look exactly like xml so those files can be imported right into scripts that then somehow turn into full blown server applications so xml gets the same attention as Json.
I’ll call it XMLlamascript
TOML v1.1 just looks like HCL.
Just use HCL at that point.
I love NixOS
Jason really should check his MQTT Server
deleted by creator
As someone who likes lua, I don’t see the problem.
Never talk to my daughter again
The very minor and nitpicky problem is that if you want JSON just use JSON. there’s still a place in the world for human readable/ editable configs that don’t require linters to be run on them after. (Current TOML is fine, I like it).
orange = { you = "glad", I = { didn\'t = { say = "banana" } } }I was such a menace with this joke as a child. Haha
I wish I could hear it again for the first time, top 10 knock knock joke
Reminds me of a good knock knock joke, but you have to start it
Knock knock
Who’s there?
Kratzkopf?
who’s Cher?
A popular singer and actress, who has got her babe, but that’s not important right now.
JSON is like the carcinization of programming
Chuck in comments and I’m on board.
_comment: “this is a comment”
Nah that sucks in so many ways thank you 😊
They were chucked out because, according to the guy who defined it, people started using them for parsing directives, which hurt interoperability because now you needed to be sure that the parser would both read the comments and interpret them correctly. Suddenly, those comments might make otherwise identical files parse differently. If the whole point is that it’s reliable and machine-readable, keeping it to the minimal set of features and not extending it any way whatsoever is a good way to ensure compatibility.
What you can do is define some property for comments. It’s not standardised, but you could do stuff like
{ "//": "This is a common marker for comments", "#": "I've never seen that as a property name, so it might be safe?", "_comment": "Property names with underscore for technical fields seem common enough as well, and it's semantically explicit about its purpose" }I’m not a real programmer but I was wondering wtf you’re on about because I don’t think I’ve ever worked with a json file in a system that didn’t use // for comments lmfao
Python, for example
And also, JSON was intended as a data serialisation format, and it’s not like computers actually get value from the comments, they’re just wasted space.
People went on to use JSON for human readable configuration files, and instantly wanted to add comments, rather than reconsider their choice because the truth is that JSON isn’t a good configuration format.
JSON was intended as a data serialisation format
Why then use a inefficient text based format instead of a much more efficient and easy to parse binary format?
Just use DER encoded ASN.1 like a normal person.
People went on to use JSON for human readable configuration files
Speaking from my own experience, “I could also use this for…” seems to be a ubiquitous programmer affliction. Single-purpose tools that are great at their thing tend to be short-lived unicorns until someone starts sticking other parts onto them for additional functionalities, taking off the horn because it’s in the way for some thing or other, and somehow we end up with yet another multi-function-tool that does a lot of things poorly.
If we’re adding comments to json, can we add canonical support for trailing commas?
Found the python guy!
Oh, a trailing comma? That’s a tuple.
Yeah when the call_func((a,)) is the way to go it is a newbie pain for sure. Remember banging my head on that one.
I’ve spent hours on that, and debugging missing commas between string literals. Even on separate lines you’re not safe from implicit concatenation.
Just make JSON5 the new official version and I would be ok
That seems quite good, not overdoing it too.
Well…
It’s name-value pairs, with groups denoted by balanced brackets. It’s close to as good as you can get for one kind of data serialization.
What is impressive is how many problems people manage to fit in something so small.
What’s it called when people try to reinvent Lisp for the hundredth time?
xml
Funny thing, Lisp structures are converted pretty easily to xml/html, so of course there are packages for Lisp varieties allowing one to write html in Lisp. (Similar to Pug, but with parentheses.)
yes, xml came from SGML which has influences from lisp, lisp can be used to represent xml 1 to 1 they have the same data model
carthinazation
Not many people realise this, but Hanibal’s dad Hamilcar Barca had a lisp, and used his knowledge of abstract syntax trees and delayed execution to deforest parts of the Himalayas in order to let his elephant of a son through.
The plural for said zealots’d be Cartholth? (singular: Carthole)
That’s not JSON. Note the use of equal signs for the property names. That’s something else.
Carcinisation is the phenomenon of non crabs to evolve crab like characteristics. It is not the process of non crabs becoming true crabs.
In this case the language is trending toward JSON syntax, but it doesn’t have to actually be JSON for carcinisation to be an applicable analogy.
So, you can say, it’s something else? 🤔
Yeah, a joke, if you look up you’ll see it.
Equals schmequals.
It could be a⇨and it would be the same as JSON because it is still a single symbol used as a separator.a distinction without a difference
Now, if it took multiple separators, each giving some specific different meaning, then it would be a something else.
It could be a ⇨ and it would be the same as JSON because it is still a single symbol used as a separator.
Nah, that’s a Ruby Hash…
schmooby schmash
Excuse me, it’s a Ruby Hash Rocket.
None of what you said makes any sense.
This is the equivalent of an anti-vaxxer denouncing vaccines because they feel that their herbs are close enough to real medicine. 🤦♂️
Don’t do that. Syntax absolutely matters.
#define EQUAL_TO =Look! I made a new programming language!
- Vaccines are not medicine. They are a more refined form of older (much dirtier and dangerous) practices of sharing sick people’s blood to create group immunity. I’m pretty thankful of not having to do the latter.
- No, herbs are far from factory produced, chemically engineered medicine.
- Most usages of herbs are defined in a way that it acts much closer to cooking. Also most of the herbs used in everyday cooking have medicinal and detoxifying properties, which is 1 of the ways food recipes have developed the way they do.
- Herbal medicine is much milder than the extremely refined medicine produced using modern methods
- Hence, they are much slower to act and you need to be using them much earlier than what you can manage with modern ones
- Hence, there is much less overdose related problems
- Most herbal medicine tend to have multiple effects. This is in contrast with modern medicine, where extra effects tend to be mostly undesirable and detrimental
- Hence, herbal medicine is a better choice for regular, low intensity problems, like the flu and what-not, rather than popping Paracetamol every time your temp goes 1℉ over the baseline.
- Herbal medicine works along with nutrition. This means, it is much harder to develop a tolerance to it in a way that would make it harder for it to work in the future.
You seem to have had something like mint and thyme in mind as an example of herbal medicine, but try to substitute something like marijuana and nightshade to see that your description doesn’t fit all of the herbs. The only thing I agree is that effects often come coupled and you have to do something to isolate necessary ones.
While marijuana and nightshade (and coffee) would be herbal “medicine” substitute for MDMA, DMT, nicotine, cocaine etc,
the others you mentioned would be a substitute for Chlorpheniramine Maleate, phenylpropanolamine and the likes.So if a herbal medicine doctor is prescribing you marijuana for cough and cold, you can perhaps consider it being a quack. Same for someone prescribing SSRIs to a functioning adult that works 40 hours a week, on their first visit.
My point was more along the lines that herbal doesn’t mean safe, mild, slow, etc
Time to read this if you haven’t already
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
The json spec is not versioned. There were two changes to it in 2005 (the removal of comments
See, this is why we can’t have nice things.
I can kind of understand it after having to work with an XML file where users encoded data into comments for no good reason. But yeah, it does make JSON awkward for lots of potential use-cases.
Anything can be abused. That’s not a legitimate reason to take away perfectly reasonable features. Looking at you, Java (unsigned integers).
Hm? Comments are not data.
They’re not supposed to contain data, but some parsers will allow you to access what’s written into comments. And so, of course, someone made use of that and I had to extract what was encoded basically like that:
<!-- Host: toaster, Location: moon, --> <data>Actual XML follows...</data>My best guess is that they added this data into comments rather than child nodes or attributes, because they were worried some of the programs using this XML would not be able to handle an extension of the format.
They are useful metadata important to the longterm lifespan of the codebase
That’s why they make sense in code and config files. JSON is neither, despite the insistence of far too many people to write configuration in it.
In an ideal world, yes. In a locked down world where you have access only to 1/4 the codebase or your job is more ontology-focused, all you have access to might be the JSON. Leaving a comment or two about why a particular value or hierarchy is as it is is sometimes more clear than writing up a seperate README that no one will read
This would undoubtedly, unquestionably happen, and it would break JSON. The only reason it works so well is because comments aren’t allowed.
As if I didn’t hate the format enough before
Iceland mentioned 🇮🇸
Almost all of those issues are solved by explicitly quoting your strings, the author even acknowledges that. Yeah it’s annoying that yaml lets you do otherwise, but the title is a bit dramatic.
Or by configuring your parser.
I do agree there are plenty of annoyances that shouldn’t exist in YAML but do because someone had an opinionated belief at one point, though. For example, it shouldn’t try to guess that “yes”, “no”, “y”, and “n” are truthy values. Let the programmer handle that. If they write true/false, then go ahead and consider those truthy. Times can also be a bit of a pain - iirc writing
12:00is supposed to be interpreted as 0.5 - but at least that’s something you can work around.But there’s plenty in that article that are only problems because the writer made them problems. Every language lets you make mistakes, markup languages aren’t any different. It’s not a bad thing that you can write strings without quotes. It’s not forcing you to do so. Anchors also make it simple to reuse YAML and they’re completely optional. The issue with numbers (
1.2stays as1.2while1.2.3becomes"1.2.3"is very nitpicky. It’s completely reasonable for it to try to treat numbers as numbers where it can. If type conversion is that big of an issue for you, then I really doubt you know what you’re doing.On top of all this, YAML is just a superset of JSON. You can literally just paste JSON into your YAML file and it’ll process it just fine.
I’m not saying it’s perfect, but if you want something that’s easy to read and write, even for people who aren’t techy, YAML is probably the best option.
Coming from powershell scripting, every string is put in quotes and to be printed strings with variables are put in
$($var)(e.g.Write-Host "Example-Issue: $($IssueVariable)")
Saves me the trouble of hoping that$($IssueVariable)isnt interpreted as a string by PowerShell.
I like this. I also like yaml, I’ve had very few issues with it and it’s nicer to work with than json.
Json’s lack of support for trailing commas and comments makes it very annoying for everyday use.
Just the other day I had a list show up as [“a”, “b”, “c”, “d”, “e”, false, “g”, “h”, “i”].
The issue was that, without me being overly aware of it, the data was going through a data -> yaml -> data step.
Yes, the data -> yaml filter was broken for not putting general strings in quotes. But IMO the yaml design invites these odd “rare” bugs.
I used to like yaml, but was happy to see Toml taking the niche of human-readable-JSON, but felt the format for nested key-value was a weird choice. However, I’ve always felt we could just have extended JSON a bit (allow line breaks, comments, if the outermost data type is an object, the curly brackets may be omitted).
Like the other person said, that’s not really YAML’s fault - just whoever decided to use YAML there.
If users aren’t intended to interact directly with the data, use JSON.
Using YAML as an intermediate format between steps of a process is a mistake. I love YAML for configuration but I’d never use it for machine-to-machine anything. If the tool you’re feeding data to requires YAML as input, just give it JSON. All JSON is valid YAML.
Edit: I realize you weren’t the one who made that decision. I’m saying the problem isn’t YAML, the problem is someone using YAML inappropriately.
I completely agree with the general assessment, but then there are always pesky exceptions. In this case the list entered a JavaScript frontend from the yaml header of machine generated content pages for the website framework Hugo. And, of course, after finding the bug, it is clear that things could have been done differently and the issue easily avoided, but I also don’t think this was a completely unreasonable design. Since Hugo actually supports JSON headers (not just via the yaml parser, but thanks for that tip!), that was a quick fix. But I’m also somewhat amazed that it was possible for the strung-together fairly standard set of Python libraries (primarily pyyaml) to not get the strings properly quoted.
Significant white-space is bullshit and i will die on this hill.
You are not alone, my friend
Is there space left on the hill? I want to join you.
I hear there’s significant space left
But it’s only white space. That’s kinda racist.
significant white space to it’s classist and racist
Their whole thing is that they don’t want to care about it, so if you get to the hill and there’s no space, you’re SOL.
Because I am not counting white space when I read. Or should we just write machine code/assembler/pick something straight away?
Because yaml is not a programming language, and debugging why your whatever you’re configuring isn’t working correctly can be a nightmare. It doesn’t tell you you missed an indent on a block, it just assumes it should be there and changes the meaning.
Braces are visually clear.
Yeah I just want JSON with optionally quoted keys, and comments.
Commas (at least the trailing ones), comments, and nothing else. JSON with type inference seems like an incredibly bad idea…
JSON5 my beloved
Preach!
If yaml didn’t have anchors and 8 different white space formats, it’d be a great replacement for this kind of thing.
But yaml is a mess, and you’d think you could parse it easily, but you can’t.
YAML is redeemed by one thing only:
All JSON is valid YAML.
No way. You’re telling me I can just write json instead?
Yup! YAML is defined as a “strict superset” of JSON (or at least, it was the last time I checked).
It’s a lot like markdown and HTML; when you want to write something deeply structured and somewhat complex you can always drop back/down to the format with explicit closing delimiters and it just works™.
I found out the hard way this is not entirely correct, as a user found a valid json that yaml parsers didn’t handle. IIRC it was some exotic whitespace issue
Yes, in true YAML fashion, there are some edge cases where things act weird but are technically correct.
As someone who works with YAML regularly:
Fuck YAML.
Nah, yaml isn’t great by virtue of itself but with what it competes with. I far, far prefer it to any other BS. Json is garbage for human creation and obviously toml due to above. XML… Obviously just for machines.
Again, only good because of its competition.
I prefer writing JSON by hand. The whitespace stuff in YAML is just such a nuisance as far as I’m concerned, which is odd as I have no problem with it in Python.
As someone who runs Home Assistant:
Fuck YAML.
I want to like yaml, I really do, but why are there so many different ways of specifying the same thing?
Is there a reason? Norway!
I have a fundamental disdain for formats with restrictive white space definitions (I’m looking too at you Python)
I’ve never had this issue with Python, but makefile has given me plenty of whitespace issues.
Should have added if it cares about tabs vs spaces.
But my vertical tabs!
import yaml:)I’m a fan of NestedText. It’s no panacea but I’d argue it’s the most well-considered and useful file format for structured data in plain text.
There just needs to be one universal standard that handles everyone’s use cases
No, for multiple standards that handle their usecase good.
If this is where the toml train ends I will be happy with it. If they do a yaml, I will be very upset.
I don’t feel like it will stray very far from what’s dubbed “TOML 0.1” in the meme. Yes, it has inline tables and as of TOML 1.1, they’re allowed to span multiple lines, so it’s technically not anymore illegal to do what’s in the meme. But all things considered, this is still a miniscule change compared to TOML 1.0.
TOML’s design is based on the idea that INI was a good format. This was always going to cause problems, as INI was never good, and never a format. In reality, it was hundreds of different formats people decided to use the same file extension for, all with their own incompatible quirks and rarely any ability to identify which variant you were using and therefore which quirks would need to be worked around.
The changes in the third panel were inevitable, as people have data with nested structure that they’re going to want to represent, and without significant whitespace, TOML was always going to need some kind of character to delimit nesting.
Well, Wikipedia does say:
The [TOML] project standardizes the implementation of the ubiquitous INI file format (which it has largely supplanted[citation needed]), removing ambiguity from its interpretation.
Nix is the next step in that evolution. It’s basically just JSON that can generate itself !
Sounds like Nix is a pathway to many abilities I consider to be unnatural.
Yeah, it really is. A plaintext document that generates an entire OS?
Is it possible to learn this power?
good thing nixers do not know the art of lisp
It’s basically just JSON that can generate itself !
You have inspired me.
I will make JSON with meta-programming
I will call it DyJSON, i.e. “Dynamic JSON” but pronounced “Die, Jason!”
It is JSON with meta-programming and the ability to call C functions from libraries
Example:
# This is a line comment # Put your function definitions up here (concat str_a str_b: "concat" "my-lib.so") # Import a function through a C ABI (make-person first_name last_name email -> { # Define our own generative func "name": (concat (concat $first_name " ") $last_name), "email": $email }) # And then the JSON part which uses them [ (make-person "Jenny" "Craig" "jenn.craig.420@hotmail.com"), (make-person "Parson" "Brown" null) ]As you can see, it is also a LISP to some degree
Is there a need for this? A purpose? No. But some things simply should exist
Thank you for helping bring this language into existence
I think you’ve just invented Jsonnet, but with C integration.
Here is the grammar:
<json> ::= <value> | <fn-def> <json> <value> ::= <object> | <array> | <string> | <number> | <bool> | <fn-def> | <fn-app> | "null" <object> ::= "{" [ <member> { "," <member> } ] "}" <member> ::= <string> ":" <value> <string> ::= "\"" { <char> } "\"" <char> ::= (ASCII other than "\"", "\\", 0-31, 127-159) | (Unicode other than ASCII) | ( "\\" ( "\"" | "\\" | "/" | "b" | "f" | "n" | "r" | "t" | "u" <hex> <hex> <hex> <hex> ) <hex> ::= /A-Fa-f0-9/ <array> ::= "[" [ <value> { "," <value> } ] "]" <number> ::= <integer> [ <fraction> ] [ <exponent> ] <integer> ::= "0" | /[1-9]+/ | "-" <integer> <fractional> ::= "." /[0-9]+/ <exponent> ::= ("E" | "e") [ "-" | "+" ] /[0-9]+/ <bool> ::= "true" | "false" <fn-def> ::= "(" <ident> { <ident> } ("->" <value> | ":" <string> <string>) ")" <ident> ::= <startc> { <identc> } <startc> ::= /A-Za-z_/ or non-ASCII Unicode <identc> ::= <startc> | /[0-9-]/ <fn-app> ::= "(" <ident> { <value> } ")" <var> ::= "$" <ident>
I had the same thought. At panel 3 it’s just oh that’s nix with commas.
Lazily-evaluated, too!
Calm down, kids. These issues were resolved a longtime ago by ASN.1
