Ignore the haters, and other lessons learned from creating JSON5
aseemk.substack.com
aseemk.substack.com
There may be a tiny bit of signal in such comments but it's mostly just noise. I try to just ignore any comment that looks like the commenter just wrote whatever came to their mind, they're gonna forget about it in 10 seconds too when they're off to the next thing to react to.
JSON is useful partially because it’s easy to parse, so parsers already exist in every language. Extending the syntax is undoing all the communal work, and encroaching on grounds that YAML and other languages already cover.
> Extending the syntax is undoing all the communal work
JSON5 takes stuff from ES5.1 and adds it to JSON, and ES5 is backwards-compatible with older JS. This means it's fairly trivial to convert JSON5 to JSON (literally 13 lines: https://gist.github.com/iddan/3d34b12f6b22c30a8a07c149b3175e...). And ES5.1 itself was the product of communal work.
> encroaching on grounds that YAML and other languages already cover.
I don't know that we should really start dividing features into nice little boxes so no one steps on each other's toes. Trying different solutions for the same problem can eventually bring us more optimal solutions than if we just sat around twiddling our thumbs because 'it's been done'. It's not like there's an army knocking on your door going "switch to JSON5 or we'll kick your teeth in." People can stick with what they want to do on the merits, but I don't see that as a reason to shut down others' work.
Did you paste the correct link? This just plumbs together an existing JSON 5 parser with a JSON 4 serializer.
How many lines does this take without importing a library the solves this for you?
JSON.stringify is part of the standard JS spec: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
JSON5.parse() is part of JSON5's API: https://json5.org/#json5parse
So any project that includes both standard JS and JSON5 could literally copy and paste this code. You're still importing JSON5, but you would presumably have to do that anyways to use JSON5.
is not a convincing reply to
> so parsers already exist in every language
You'd have to rewrite anything using json_encode() and json_decode() in PHP, or the equivalent standard functions/methods in Python, C#, etc. And also take on another dependency. And maybe lose performance.
And then you sometimes may have to know whether you're dealing with JSON or JSON5, and what the program on the other end of the line produces or expects and can handle.
For new greenfield projects it might be worthwhile. But most of the world runs on legacy code and many prefer to stick to the standards and minimize dependencies. So it's not that simple.
That doesn't mean it's bad though. Like anything else in software, it's a trade-off.
This take is disingenuous and horribly uninformed and very shortsighted.
Not every parser out there is JavaScript eval(). Some people actually had to write and maintain a parser in whatever programming language they have to work with.
In the past I wrote a JSON parser for a low-level language, and back then I had to write the letter and parser by hand. Each change to accepted JSON values meant I had to add at least one terminal token, update the grammar to include it, and update the data model to support yet another type.
Adding comments would either require adding a terminal token to be ignored, or rewrite the data model to support positional items that cursors/iterators could or could not skip.
These are not 13LoC changes. At all.
And if I happen to be consuming an API I don't control which for God knows what reason decided to move to json5, I would either have to rush a parser to production or remain down.
> And if I happen to be consuming an API I don't control which for God knows what reason decided to move to json5
And such a decision might be the API maintainers not understanding their users.
This really does look like a case of missing a point and proceeding with a bad idea that results in an all around increase in harm, because no matter the idea, there will always be at least a few adopters and then everyone else has to deal with it.
If it's allowed for anyone to come up with any new idea they want, then it has to be equally allowed for others to criticize. Anything else is literally not sane.
It's perfectly likely the "haters" are right and the idea is bad and should not be adopted or proliferate. It's also possible they are merely unthinking haters.
But calling them "haters" is not a valid defense of the idea.
Never disputed this.
> It's no longer better ergonomics if you can't use it at all because half your endpoints don't support it
Incompatibility != lack of ergonomics. People use new and incompatible frameworks all the time. It could be argued that JSON had better ergonomics at a time when XML was more popular, in spite of impedance mismatch with other APIs. Similar could be said of what's happening with python 3 vs python 2 the last decade. How do standards improve without breaking anything?
> But calling them "haters" is not a valid defense of the idea.
From reading the article, it seems like people were particularly cruel, well beyond constructive criticism into straight up ridicule:
> But he went even further: Mitchell took the time to make a parody project of JSON5 [..] even making fun of me by name.
OP was gracious about it however:
> I reached out to Mitchell as part of writing this post [..] I assumed he regretted it in retrospect, and I harbored no grudge or ill will towards him.
> Mitchell confirmed this assumption to be true and offered a genuine, sincere apology. Thank you, Mitchell — I appreciated that a lot.
He doesn't appear to take personal affront, so I think his use of the term 'haters' is playful, but I think also fair when you consider that even those mocking them felt bad about their conduct.
You can disagree with someone without accusing them of being insincere or arguing in bad faith (which is what “disingenuous” means).
We're supposed to assume best intent.
Accusing someone of being "disingenuous", "horribly uninformed" and "short sighted" for providing an different opinion isn't doing that.
I learned something from the post. I learned that these enhancements are already mostly being codified in the language.
That influenced my opinion on the subject.
I assumed that the 13 lines of code comment was in the context of js, not (for example) a c parser, where it's pretty normal for 13 lines of js to translate to hundreds or potentially thousands of lines of C code.
The post was informative and respectful.
The name-calling response was not.
No one with the faintest understanding of what a parser is and does would ever claim that any of these changes could ever take 13loc to implement.
If they are ignorant and still feel compelled to pass false claims on how significant changes are instead trivial just to try to downplay the real world challenges, they are undoubtedly being disingenuous.
Rather than write this:
> This take is disingenuous and horribly uninformed and very shortsighted.
Write this instead: "This take is horribly uninformed and very shortsighted."
Think of this way: we're asking if you can find ways to not assume bad faith in another party.
> If they are ignorant and still feel compelled to pass false claims on how significant changes are instead trivial just to try to downplay the real world challenges, they are undoubtedly being disingenuous.
From the Apple dictionary:
>> disingenuous: not candid or sincere, typically by pretending that one knows less about something than one really does: he was being somewhat disingenuous as well as cynical.
Since this behavior is so common, apparently it works, evolutionary:
It makes others think your are smart, for a long while
And not much effort required, on your part. So, a great opportunity?
And the more popular the project you start bashing is, the smarter you'll seem? Corollary: If one builds something great, one will get dissed by some.
Also, I think it’s very poor character to say on one hand that people’s reaction doesn’t bother them and dedicate a third to a half of the article to Mitchell’s criticism specifically. I think Mitchell’s criticism is completely reasonable (I remember this as an era of “solving json” through multiple alternative formats) and drawing attention to what seems in retrospect as a mean-spirited act is actually quite a cynical attempt to strip the context of it and deliberately cast Mitchell in a poor light. Mitchell’s intention is very clearly a technically minded one to nudge people away from trying to massage long term, durable standards in often trivial, subjective ways with an end goal that can only result in format thrashing that doesn’t ever address anything substantial.
Additionally in terms of the criticism, I observe the inverse phenomena to what you describe. You say that popularity isn’t a good indicator of goodness, but I think the inverse is goodness isn’t an indicator of eventual popularity. Some very elegant solutions just aren’t flexible enough for the real world. It is short sighted to try to argue some objective definition of badness because it doesn’t solve a problem you have or doesn’t fit your version of what a product like that should be. Sometimes in the absence of perfection people just have to get work done and want tools that make that easier.
I think that’s the sleight of hand occurring right, it’s reasonable to say he might mot have linked to it, but the purpose of the repo was not to shame the author. It might be my own predilection, but it strikes me as dishonest to say “I didn’t mind this” and then imply the opposite.
> Additionally …
Right, me too, they both occur. I don’t think I actually specified an argument as to why json5 is bad or even argued that it was. My comment is mainly about the article itself.
This whole paragraph reads as an argument to not use json5 given that it is very much trying to perfect the imperfect json, which most people just get on with.
https://nigeltao.github.io/blog/2021/json-with-commas-commen...
The "Why not JSON5, JSONC #1, HJSON or HOCON instead?" answer says it's because of "unquoted strings", then links to a section that only talks about unquoted values. JSON5 doesn't have unquoted values.
https://github.com/babel/babel/blob/b1e73d6f961065c56427ffa8...
Everything else is a matter of taste, and who really cares.
As long as we're clear that JSON5 never gets a .json extension, what is the problem?
Just adding comments and multi-line strings doesn't make it human-readable, it is still too bloated and I don't like writing it manually. If you want a human-readable format, try at least to remove unnecessary quotes, brackets and commas and make it look similar to YAML.
JSON is not intended to be used in configs and other user-editable files.
The interesting question I think is, why do you think json is so used in that capacity despite not being meant for it? Why YAML, despite being so widespread, hasn't swept json away for those purposes? (let's for a moment ignore that YAML can go REALLY nuts, and think only of the simplest version of it)
But we can't ignore it… we have to validate and make sure it isn't going too nuts. And we will probably fail at that.
In a small file, semantic indentation is beautiful. In a large file where you have to scroll and scroll to find out where you are, it's a pain. And perhaps importantly - can't be autoformatted. Your IDE doesn't know what indentation level you intended, and without braces/brackets to tell it, it can't detect errors.
There's parsing automagic wackiness if you're not careful (the famous example: country abbreviation NO for Norway becomes FALSE).
The nice feature of references is almost never actually used in practice. An incorrect or circular reference can look fine but badly break things.
Yaml typing is application (and version) dependent so not really useful.
There's more, but basically JSON, though simpler and uglier, prevents all of those. You can, and pretty much have to, use an alternative 'safe YAML' parser, but even that doesn't solve some of the problems.
It's a primary goal of JSON, it's fair to question whether it's successful at it. Personally, I'd much rather write TOML or S expressions. I don't like YAML at all, the whitespace sensitivity drives me nuts.
TOML is just plain unreadable to me when I have to figure out what I'm looking at: I convert it to YAML to both read and write it when I have to add new lists/maps.
Give me YAML or JSON at least they make sense.
Notwithstanding which, I too would prefer to interchange data via S-expressions.
+1 on those S-expressions.
My point being; aspects that seem like irritating omissions now, may have been editing decisions instrumental in the overall adoption of the standard.
We can say the underlying idea of taking javascript's object syntax was a discovery, but he refined it between discovery and release.
Yes, but it’s a bit late for that.
It sounds like you’re advocating for a configuration format somewhere in the space between JSON and YAML. Not JSON, because it’s annoying to write by hand, no comments, no trailing commas. Not YAML, because of all those unintuitive edge cases like “no” (unquoted) being a Boolean.
It sounds like the primary disagreement here is where in the design space between JSON and YAML is the right syntax for configuration files.
That just shows poor judgement on behalf of the developer who made that decision, not a failing of the language.
I don’t see how assigning blame is productive here. People choose the wrong language, wrong library, or wrong tool all the time.
Not really. JSON offers no challenge in editing by hand. All comments I've seen in this thread boil down to people trying to pass off whimsical nice-to-haves as this sort of insurmountable problem.
I mean, I do like a nice git history with small diffs. Not supporting trailing commas is unfortunate as it can cause the trailing line to show up in diffs if you add a comma there. But is this a problem? No, it is not.
Let's be honest here: JSON5 solves no problem worth solving, at the expense of breaking compatibility.
At the end of the day, you can do anything you need to do in C.
What's the point of having all these other languages?
That's not the problem, is it?
The choice you're faced with is breaking compatibility just to add little to no value.
The problem I have is, I need a configuration language that is human readable, familiar to developers without teaching (anybody who knows JS, or to some extent Python and PHP), is also machine writable, and supports comments. The only language that supports this is JSON+comments (next contenders would be INI (!) and then XML). JSON5 just helps by giving it a name, a consistent implementation, and packages for many languages. I've rolled my own JSON+comments (or "static subset of Python / JS literals") multiple times, and am glad there is a community standard now.
The trailing comma is really an issue, because it works in JS, and it is an arbitrary restriction in JSON. If you learn JSON on the job (and think of it as "JavaScript Object Notation" i.e. JS literals) then you will run into this, and it causes unneccessary frustration.
Since every JSON5 package I know produces valid plain JSON, compatibility is never an issue.
I'd say if those were your criterias and you still stuck with a JSON-derived language, your decision-making process was a colossal failure in oversight, given the myriad of options around such as TOML or even YAML.
But let's pretend that adding comments and trailing commas to JSON makes any difference regarding those requirements.
YAML has a data model like JSON, but it is disqualified for me by the syntax ambiguities.
The easiest thing is if people could just write JS (or Python) object literals, but restricted to plain old data, and without the ability to call functions etc.. JSON5 gives exactly that.
This really... doesn't matter. Humans read and write it all the time. If everybody is getting annoyed at it because they're reading it, they have every right to wish it was more human-readable, hence trying to make it so. There's nothing wrong with that.
Regarding the criticism, I get the same bad energy when people get a kick out of fixing someone’s grammar, and then do not even comprehend what is being complicated.
Well done on the lib and thanks for building something useful! Good writeup also! Think I’m going to give the commit access trick a shot.
And what problem would that be?
Pray tell, which intolerable experience did you ever had writing JSON by hand?
Lack of multiline indentation-ignored strings.
"Ignore the haters" reads like: "I ignored all criticism of my idea, and some other people like it anyway.".
There's already so many terrible technologies in the web programming domain that have plowed onwards in the face of so much criticism, and now we're stuck with them. Part of being a good programmer is being humble, and accepting that you might not have all the answers, the best ideas, or see the bigger picture.
I’ve always wanted comments in JSON, but the other issues highlighted are not things I care about. The ‘be lenient in what you accept’ philosophy is a disaster, just look at HTTP… stricter is better IMO.
If you did, I guess it would be anywhere that you had a description in the OpenAPI document. But I wouldn't do that.
As a concretr example, this is a common big problem for NPM, and they have to resort to blocking IPs and/or CIDR ranges.
I don't think you understand quite how many 60,000,000 downloads per week is if you think a big company's CI pipeline might account for that.
I'll never understand why those companies can't bother to set up an internal mirror.
There aren't that many companies in the world basically.
For some companies release just means another merge to master, so they are doing tens/hundreds releases a day.
Once you do enough development that this matters, you're going to be doing caching or you'll be wasting money on waiting and bandwidth.
Consider that for developers a slow build = break time. https://xkcd.com/303/
And just running npm or pip at every turn is easier than setting up all of that, so there needs to be a push to do it. And the server of those entities seem to be able to deal with the load.
In my first job we had autoscaling cloud servers that took 30-40 minutes to be operational. I told my boss we should have pre-created an image instead of installing and compiling dependencies when we started them. But he said it would not be agile.
Yes, they do. Mostly as a result of looking for infra savings, optimising job time, improving reliability after some process fails when npm is down. It takes some longer than others. It's not necessarily devs that will do it either.
> JSON5 is in the top 500 by both dependents and PageRank
that probably confirms the project is significant but doesn't answer your question.
Didn't knew about this json5 thing but I'll try to use it instead.
* my belief that people who execute on some project are inherently superior - they made a thing to solve a problem! Automatically superior to people who didn't make a thing
* the Blub Paradox http://paulgraham.com/avg.html I can only judge projects accurately where I am operating at a higher-level of thought. If I don't get the need, then I am probably not operating at a higher-level than the author. I prefer to be able to have sufficient Theory of Mind thinking that I can inhabit the author's mind to see why they need something, make the best case for it, and then reject/accept it if I have to. There are many places where I can't. The most trivial example which everyone grasped before I got there is GraphQL as an API specification and IDL, which I only recently really grokked.
In any case, I had a figment of the idea that you talk about which is the "people who won't be your users". Thanks for citing the thought around that.
Congrats and good luck!
0: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
But if they don't convince me I'm wrong, then I ignore them. :)
What if, though, they convince others that you're wrong -- so no one wants to use your software?
(although it would have been helpful to many)
I can post my counterarguments and then the other folks can decide. If the argument is compelling and cogent, people listen.
But I know I'll never convince everyone to like my stuff. The goal is to make a quality, useful product while listening to good suggestions for improvement and not letting people get you down.
Yes, ... Maybe ... I hope software people do; maybe they pay a bit more attention to logic and reason.
I'm otherwise reading the book "Influence, New and Expanded: The Psychology of Persuasion", and I no longer have such high expectations :-(
> not letting people get you down.
Good point :-) (Thanks for the reply)
https://news.ycombinator.com/item?id=30449263
While there were some really good comments, the vast majority were very negative and critical. (BTW: the comments on HN were much more civil than on Slashdot where the story also got picked up) Still, I didn't ignore the criticism but tried to learn from it and there were some encouraging comments mixed in as well.
When you say "While there were some really good comments, the vast majority were very negative and critical" it sounds like you think that negative or critical comments cannot be good.
We tend to pay more attention to the negative and dangerous -- a survival thing, right (from when we were hunters and gatherers)
Slashdot stopped being a worthwhile place to frequent at least 10 years ago. It's devolved into an utter cesspool, since all the quality people fled for greener pastures ages ago. I recommend ignoring its existence altogether at this point, along with any comments from that site.
Or search for “gnaa”, but not if you’re on a corporate network.
I believe VSCode uses json5 with .json extension for a whole bunch of their configs.
It would be a slower parser than JSON though.
I have long held the belief that if the audience of Reddit or Twitter or Slashdot or Hackernews universally hates something with such vehemance that you doubt your own thoughts then you are probably doing the right thing.
In the words of Casey Neistat, in his video "Do what you can't." - "To the haters, the doubters, my 7th grade vice principal, to everyoneone who has ever anyone with a dream they can't..."
This is not "all negative feedback" or "that it should be ignored by everybody" or "treated as a positive sign" and it is disingenuous of you to imply otherwise or to conflate it as such. I'd like to introduce you to a video between a psychologist and someone with an agenda: "So what you're saying is..." No, that's not what I am saying at all. I cannot decide if you have poor reading comprehension or want to twist someone's words. Perhaps both. I'm done with this discussion with you because I'm not going to engage with someone who suffers from the former or wants to engage in the latter.
"If you've found something that arouses interest and debate, you might be on to something"
And critique, or a gathering of enemies, is interest in something
(interest in the stuff the enemies in the game are guarding)
What is even the point of soliciting feedback if you will take a universally negative response as a positive?
Of course what you mean is for javascript to have a timestamp literal. Well, the closest equivalent would be: `new Date("2021-12-17T03:24:00")`
It's cumbersome, but I would accept it:
{ mytimestamp: new Date("2021-12-17T03:24:00") }Keep it simple.
despite popularity, most of the technical comments in that original thread aren't wrong. 'Popular', 'Easy to adopt' and 'a very bad idea' can be overlapping circles, in particular in the world of javascript and npm
This is not wrong per se, but it calls for much more complex code which handles all the edge cases, and hurts performance at the end of the day.
Then, this small performance penalties pile-up and the same developers ask why their code is not working as fast as it should.
I don't call for very pedantic formats, and extremely hand-optimized systems. I just wish there was some more awareness of the trade-off they're making and making small inconvenient, but technically lighter trade-offs, these codebases can obtain very dramatic speedups.
The generation that learned with BASIC or used Smalltalk or Lisp in college is decidedly an older generation at this point.
If performance is important, you profile. Optimizing your configuration format for parsing speed is likely a bad decision unless you’ve identified that it’s a problem.
Young programmers have a tendency to err in both directions, here.
Some will err by building on lots of complex systems tied together. They’ll fire off “create-react-app” on day 1, and then on day 1000 they realize that there’s just too much going on that they don’t understand and can’t debug.
Some will err on the side of rejecting “heavy” dependencies. They overestimate their knowledge of the problem domain, underestimate the flaws in code they are planning to write. They’ll create a blank repo on day 1 and on day 1000 still be working on support code that they didn’t have to write.
If you have years of experience, it’s easier to navigate the middle path. The incoming generation will figure it out given time.
I personally prefer to choose a simpler, and a bit more pedantic versions of stuff whenever I develop something, and while it doesn’t break performance records OOTB, the performance is always beyond reasonable at the first iteration.
So with this logic, I’ll just prefer “vanilla json” whenever I need to use it as a data exchange format, or a well established and fast XML parser, and leave at it.
This logic made my life way easier, but it’s just me, and I respect other developers’ choices.
Mine is just an observation rather than a rant.
OTOH, using a simpler set of components will reduce the probability of breakage a lot, too.
In my experience, some of the projects which have been most valuable have been those which follow a theme of ‘do something really horrible or annoying inside our program so that the users don’t need to deal with the nastiness’. For example it might mean having to write code with some unpleasant hacks or in a very weird way to fit underlying apis or performance requirements; or it could mean spending a bunch of time manually tuning some heuristics because those heuristics improve the library.
is-odd
The haters were also wrong. They completely misunderstood the needs of the target audience for JSON5. They forgot the world is a messy place, no matter how clean and clear the JSON spec may be, the input from random users may well be messy...
I'm guessing even you simplify your life by using autocorrect and spell check from time to time. Autocorrect has its issues too, it probably makes us lazy and sloppy, but on the whole, it improves the input experience for a lot of users, so on balance, people choose to keep it around.
Like Hashicorp products or not, the remark seems a bit petty.
More details in this comment: https://news.ycombinator.com/item?id=32380944
I completely understand the reaction and find his repo a very appropriate response.
But for a second it makes them feel smart.
Left-pad shitshow showed how relevant NPM dependency chain is as a measure of quality and what it does for the ecosystem. This is left-pad with added complexity to sneak in malicious code.
> I’m sorry about it, I’m sure it was offensive in many ways. But while clear in hindsight, I certainly didn’t realize it at the time. Its not an excuse, but I was 21 years old at the time and my EQ was well… under-developed. I didn’t mean any harm, I was mostly having fun with it, and I’m happy to hear your project is doing well. Anyways, congrats on the success, sorry for the unkind gesture, I would never do such a thing anymore.
Aseem accepted my apology, and I'm very happy to see his project succeed the way it has! I obviously disregarded the project and he proved me (and many others) wrong!
These were not haters. They in fact went our of their way to give arguments supporting their verdict, and in some cases even constructive suggestions like "make that a preprocessor instead".
Your piece does not make you look like the smartest guy in the room, vindicated by success and adoring fans. It makes you look like someone who confuses internet fame points with something that actually means something. Like a sore loser who needed to convince themselves that they really are the smartest person in the room.
The internet is a trap. No matter how bad your idea is, you will always find people who think it's great.
Just look how many people Alex Jones found who agreed with his Sandy Hook ideas.
Don't go looking for fans. Go looking for people who disagree, as they will help you improve your skills and grow as a person.
If you were actually as good as you apparently think you are, you wouldn't be wasting time writing text like this. You wouldn't need to. Your work would speak for itself. I don't remember Mozart or Einstein lament about their haters.
Someone online told me another library (released after mine) was doing the same thing.
Turns out other library has very obvious bugs, is 20x times slower, but it has 8x more downloads.
Yep downloads are not a metric of quality.
Can't say for sure about Mozart, although I really would not put it past him to do so.
But here's Beethoven doing the same thing: https://quotepark.com/quotes/2122354-ludwig-van-beethoven-o-...
It is partly the articles, but more the comments (and careful modding).
HN stands out as a great place to expand my awareness. There are people here with deep technical experience that care about the outcome of their conversations. The flame-bait and regressive behavior isn't the main thing going on, it is a sideshow. If that ever changes for me, I'm out of here.
The article fodder is not as interesting to me as it used to be, but there are gems, and the comments remain engaging.
Who knows, perhaps I'm one of the jerks? Perhaps I'm the dreamer that dreams the dream and am therefore the jerk expert? Hard for me to say, but I welcome your opinion.
> ...Most of the users of this site...
> ...think they're more brilliant...
I suppose the above critiques are not directed at yourself?
If the performance of your module suffers from parsing its inputs, you are doing some Really Terrible Thing with your inputs. And if the nature of the task really requires you to parse data quickly and on a big scale, it would be better to ditch JSON altogether and switch to a binary format like protobuf instead.
You know that something has gone very deeply wrong somewhere when people oppose your project because they are ideologically opposed to comments. In my own experience, finding out that many JSON parsers reject comments was a real WTF moment, and a deal breaker for my config-file application, so I ended up using JSON-plus-comments for it instead of JSON. At the same time, lack of support for trailing commas and unquoted member names have been a minor but persistent thorn in my side for no good reason. The justification for not having comments in JSON is that in the great disaster that was XML, some projects would parse the comments and take them as semantically significant. However, the real problem there was that parser libraries would expose the comments, and that some generators would put important information only in comments. But I think that these mistakes are unlikely to be repeated, and that the proposed alternative - moving all comments into the markup, or eliminating them entirely - is just obviously worse.
One of the things that ruined the XML ecosystem was a persistent belief that XML was to be read and written by machines, combined with a reality in which it was mostly used for human-written config files, leading to a tolerance for awful syntax (like prefixing every single attribute with a namespace, and the ridiculous CDATA notation). I'm seeing the same thing with JSON: A significant fraction of its use is for human-written and human-read config files (which often desperately need comments) and people are pretending it's strictly a data interchange format that shouldn't be used for that.
It is sometimes said that JSON was discovered, rather than invented - that the syntax was already out there. So it is with JSON5: There is nothing new in this, it is simply return to JavaScript Object Notation and bringing in the rest of what Javascript has.
So, all you pooh-poohing ideologists: please seriously rethink whether disallowing comments, trailing commas, and quoteless member names is actually a good idea. Consider this in light of the fact that JSON is widely used, today, as a config-file language, and that {"--":"This is a comment"} is ridiculous enough that no one does it in practice, can't be inserted on any line, and invites consumers of your data to parse the comments.
Json is trying to square the circle of "I want things to be easy" but also "I want to not shoot myself in the foot", goals which are mutually exclusive. Every new version of json is just gods way of teaching people how XML got to be the mess it is.
If C was written like
{if {x == 1}{
{return {x + 1};}
}
Also your syntax is terrible. There are already s-expression versions of c:
(if (== x 1)
(return (+ x 1)))I mean, I guess you know what each tag is closing, which is more than you get with ))))...
That is not the job of the data format, that is the job of the meta data format. That this is still a draft tells you how far behind json is: https://json-schema.org/draft/2020-12/json-schema-core.html
Again, json is gods way of teaching bad devs why xml is such a mess.
In theory maybe. In practice it's really nice that all JSON documents have the same standard handful of basic datatypes (number, string, etc.).
> Again, json is gods way of teaching bad devs why xml is such a mess.
Maybe that's the lesson bad devs take from it. Good devs take something rather different from it.
You missed boolean. That's it. Those are the supported types by json. But tell me more about how you can guess the type of 1515151515151 without context.
>Maybe that's the lesson bad devs take from it. Good devs take something rather different from it.
Thank you, people like you are the reason why I can quit my job and any time and find another one paying mid six figures to fix your messes.
In JSON if that's an expression then it's a number. You're the one advocating S-expressions, which is where you'd have to guess the type, so tell me how you'd figure the type out there. Heck, you're complaining about the fact that JSON schema is only a draft, but that's still decades ahead of the state of standardised S-expression formats.
> Thank you, people like you are the reason why I can quit my job and any time and find another one paying mid six figures to fix your messes.
Right back at you lol.
eval(a)
There's only a single JSON ISO standard (21778:2017). Why do you feel compelled to comment on topics you don't have knowledge about?