JSON is like the carcinization of programming
I love JSON. But I really wish there was a standard that allowed commas with no following items and that there was a syntax for comments.
Chuck in comments and I’m on board.
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.
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
I did say “I’m not a real programmer” heh 😮💨 I just thought // was standard for comments across all json files
No biggie, I just named an example. Even “real” programmers, whatever definition you want to use for that, don’t know all languages.
But yes, many languages do use // as comments and particularly the Javascript environment it originally stems from does. Python (
#) and SQL (--) are the only examples I interact with frequently enough to know off the top of my head (but SQL still recognises/* ... */for delimited comments). XML/HTML also has<!-- -->for comments, but that’s not so much a programming and more of a description language.
_comment: “this is a comment”
Nah that sucks in so many ways thank you 😊
What’s it called when people try to reinvent Lisp for the hundredth time?
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)
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
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.
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.
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
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.
orange = { you = "glad", I = { didn\'t = { say = "banana" } } }Time to read this if you haven’t already
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
As if I didn’t hate the format enough before
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.
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$IssueVariableisnt interpreted as a string butbas a variable by PowerShell.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.
Iceland mentioned 🇮🇸
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?
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.
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!
import yaml:)
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.
Significant white-space is bullshit and i will die on this hill.
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.
You are not alone, my friend
Because I am not counting white space when I read. Or should we just write machine code/assembler/pick something straight away?
Not sure I’m following the jump from significant whitespace to machine code. How are those related?
Human and machine read differently. If you ignore that (in case with indentation), then why bother with writing human-friendly form of code, when what is going to be really executed is something else?
If anything, that sounds like an argument in favor of significant indentation, not against it. Humans and machines read differently, yes, which is why we tend to add whitespace and indentation to code even for programming languages where it’s not significant. We do that expressly because it makes the code more human-friendly, so it’s quite the opposite of ignoring their differences.
No, it is an argument against it. We indent code so that it is more comfortable to read it, not in order to make it easier to understand
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.
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).
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.
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.
As someone who likes lua, I don’t see the problem.
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).
Never talk to my daughter again
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.
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.
I love NixOS
TOML v1.1 just looks like HCL.
Just use HCL at that point.
Calm down, kids. These issues were resolved a longtime ago by ASN.1
I think edn is almost the only more advanced and ergonomic option to json. Edn is like the evolved json, but its interesting that its roots are way older than JSON.
The fact that you can very efficiently define whole applications and software just with edn (and the lisp syntax in general) is what makes really amazing.
I think this blog post sheds more light on how we only need lisp for defining data and applications.
I’m a daily Clojure user, and I knew immediately where that article was going, but it was still a delightful and insightful read! Thanks for sharing!
deleted by creator
That looks a lot like HCL / Terraform / OpenTofu.
That’s literally just lua tables
