Ignore the haters, and other lessons learned from creating JSON5(aseemk.substack.com)
aseemk.substack.com
Ignore the haters, and other lessons learned from creating JSON5
https://aseemk.substack.com/p/ignore-the-f-ing-haters-json5
210 comments
Many of those original comments were pretty spot on though. Maybe the constructive criticism you need sometimes is “don’t do this”
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.
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.
This seems like making a mountain out of a molehill.
> 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.
> 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.
> 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).
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.
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.
Saying the take is “disingenuous” is certainly a rude and inappropriate response.
You can disagree with someone without accusing them of being insincere or arguing in bad faith (which is what “disingenuous” means).
You can disagree with someone without accusing them of being insincere or arguing in bad faith (which is what “disingenuous” means).
It is disingenuous to reply to a comment about "undoing all the json parser work across multiple languages" with "no it hasn't it's just 13 lines in javascript see!"
It is potentially uninformed, possibly mistaken, but not disingenuous.
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.
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.
> We're supposed to assume best intent.
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.
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.
The commenters above (who I agree with) are suggesting the following, I think:
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.
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.
So it's at best disingenuos or ignorant, merely not necessarily both.
Comments is clearly for configs, not for server responses, but even if someone did respond with json5, as the previous post said, you don't have to tokenize the json5, you can convert it to json first (since I would imagine you don't need comments). I can imagine how you feel about graphql.
I agree with your point here (but I'm not the GP). The main thrust of the article is about finding product/market fit, and it could be said here that the market isn't the parser writers, who would be disrupted, but the developers who want a JSON format with better ergonomics.
> 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.
> 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.
It's no longer better ergonomics if you can't use it at all because half your endpoints don't support it, and the reason they don't support it is not mere neutral time or popularity but a result of the fact that the new form no longer posesses the qualities that made the original form useful.
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.
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.
> 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.
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.
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.
If you happened to use an API that switched to XML or whatever other thing you’d be in the same boat. What a ridiculous argument.
> This means it's fairly trivial to convert JSON5 to JSON (literally 13 lines: https://gist.github.com/iddan/3d34b12f6b22c30a8a07c149b3175e...).
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?
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?
JSON5 parse constructs a Javascript object, which can in turn be serialized by JSON 4 into valid plain JSON string. That's not an invalid way of converting the two objects.
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.
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.
> So any project that includes both standard JS and JSON5 could literally copy and paste this code
is not a convincing reply to
> so parsers already exist in every language
is not a convincing reply to
> so parsers already exist in every language
Personally, I like some of the ideas of JSON5, but it isn't compatible with JSON as implemented. Altering existing systems to use it isn't as trivial as you imply. And requires taking on new dependencies.
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.
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.
What about the vast majority of languages that aren’t JavaScript?
> can make the author of it feel smart for a second
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.
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.
I think the real lesson is that popularity is a poor way of understanding whether something is actually useful or good, it can indicate those qualities but meaningless without also applying our reasoning faculties too. The author appears to remain oblivious to any of the very good reasons why people don’t like alternative json formats and incapable of incorporating that into their understanding of people’s reaction. Citing market mechanics as a justification of “popularity = value” is blowing past the many examples of where free markets produce terrible approximations of value.
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.
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.
Except Mitchell explicitly called the author out in his satire and the author was right that Mitchell thought in retrospect it was a mistake to do so. Why is it in poor character if he’s expressing a view Mitchell agrees with.
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.
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.
> Except …
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.
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.
The only 2 things I'd like to add in JSON are trailing commas and comments, and this is already supported in most JSON configs (.eslintrc, .babelrc, ..), it's called JSONC I believe
To each their own, but I find mandatory quoted keys a pain in the ass, and once you change those three things you're basically at JSON5.
I kind of wish Apple hadn't deprecated NeXT-style property lists and had instead gone in the direction of GNUstep by trying to improve the classic format.
.babelrc uses JSON5. ;)
https://github.com/babel/babel/blob/b1e73d6f961065c56427ffa8...
https://github.com/babel/babel/blob/b1e73d6f961065c56427ffa8...
Another name for this is JWCC. IMO very good argument for this feature set here:
https://nigeltao.github.io/blog/2021/json-with-commas-commen...
https://nigeltao.github.io/blog/2021/json-with-commas-commen...
Note that that page forgets to actually make an argument against unquoted keys.
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.
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.
A native set type would be nice too, and the syntax for it is obvious— comma separated values like a list, but enclosed in braces like a dict.
A set is just a list with a uniqueness constraint. JSON already has a list type.
Proper support for dates too.
I think the only valid objection here is that calling it json5 implies that it is an offical new version of json by the same people who brought you json. That's misleading and bordering on unethical in my opinion.
Everything else is a matter of taste, and who really cares.
Everything else is a matter of taste, and who really cares.
[deleted]
Whenever I need to use JSON in my projects I always check if I can use JSON5 instead. It really makes a difference to have a more user friendly format. My only gripe is when I use Python, the official JSON5 module is much, much slower than Python's JSON parser. I frequently end up translating the development JSON5 files to JSON files that go into the final runtime because of this.
I'd never heard of JSON5 ahead of this post.
As long as we're clear that JSON5 never gets a .json extension, what is the problem?
As long as we're clear that JSON5 never gets a .json extension, what is the problem?
As much as the spec for this looks like a list of features that one hardly believes are absent from the original JSON, this just makes things worse as you now have to check which type you're working with, as if there are already not enough places for things to break.
https://xkcd.com/927/
https://xkcd.com/927/
Honestly I don't understand why JSON should be human-readable. It is a data serialization format intended to be read by software.
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.
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 first two sentences of the text on http://json.org are "JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write."
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.
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.
Douglas Crockford usually says he discovered JSON, and subsequently named it and wrote a specification, and I think this precludes suggesting it had design goals, because it wasn't an invention. More broadly, I also think this understanding of JSON's origins absolves the discoverers of its limitations, and opens the door to talking about improvements and variations.
Notwithstanding which, I too would prefer to interchange data via S-expressions.
Notwithstanding which, I too would prefer to interchange data via S-expressions.
He made changes that were based on design goals. He simplified a few parts, and removed comments with the explicitly stated goal of avoiding parsing directives.
We can say the underlying idea of taking javascript's object syntax was a discovery, but he refined it between discovery and release.
We can say the underlying idea of taking javascript's object syntax was a discovery, but he refined it between discovery and release.
This seems to merely be applying Saint-Exupéry's rule as an editor, which is a matter of baseline competence, and hardly seems worthy of description as a goal of any sort.
I don't follow your discovery/goal-less-ness argument. Why couldn't one of the things present in his discovery be readability?
+1 on those S-expressions.
+1 on those S-expressions.
Early versions of JSON supported // comments. As Crockford tells the story, they were removed because folks were using them for pragma, leading to interoperability issues, and because several parser authors working in languages other than Javascript reported surprising levels of complexity when implementing comments.
My point being; aspects that seem like irritating omissions now, may have been editing decisions instrumental in the overall adoption of the standard.
My point being; aspects that seem like irritating omissions now, may have been editing decisions instrumental in the overall adoption of the standard.
I don't get how anyone uses TOML. YAML is whitespace sensitive but it's python rules and quite sensible.
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.
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.
You are not alone, I find TOML awful to use and hate when I get forced into it.
Give me YAML or JSON at least they make sense.
Give me YAML or JSON at least they make sense.
> JSON is not intended to be used in configs and other user-editable files.
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.
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.
KDL comes to mind : https://kdl.dev/
See edn extensible data notation. https://github.com/edn-format/edn
> Yes, but it’s a bit late for that.
That just shows poor judgement on behalf of the developer who made that decision, not a failing of the language.
That just shows poor judgement on behalf of the developer who made that decision, not a failing of the language.
Right… and the fix is to switch from JSON to JSON5.
I don’t see how assigning blame is productive here. People choose the wrong language, wrong library, or wrong tool all the time.
I don’t see how assigning blame is productive here. People choose the wrong language, wrong library, or wrong tool all the time.
> Right… and the fix is to switch from JSON to JSON5.
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.
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.
> Let's be honest here: JSON5 solves no problem worth solving, at the expense of breaking compatibility.
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.
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.
> 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.
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.
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.
TOML is basically INI. It adds nested sections, but it is not so obvious how to use them. And the data model is more complicated, with sections first, and in each section a key-value map.
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.
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.
Under that argument, why bother improving anything?
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?
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?
> Under that argument, why bother improving anything?
That's not the problem, is it?
The choice you're faced with is breaking compatibility just to add little to no value.
That's not the problem, is it?
The choice you're faced with is breaking compatibility just to add little to no value.
I read and write json manually almost every day. I haven't bothered to insert json5 in our pipelines for various reasons, but I sure wish it was the default.
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)
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)
I used to think YAML would be great for that sort of thing. Now, having dealt with some large YAML files, I understand at least a couple of reasons why people don't like it for that. Things that are invisible when visually looking at a file, and not really detectable by IDEs or linters or anything (because they would have to assume your intent).
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.
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.
References are used quite a bit. Look at OpenAPI; they're critical to that effort.
> 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.
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.
Also, "human-readable" is somewhat of a relative term. I can read a hexdump of many binary protocols as easily as I can English, and over a billion humans can read a language that seems impenetrable to the other several billion on this planet.
Because it's really handy to be able to run things like rest requests without any tooling more than curl or postman?
> It is a data serialization format intended to be read by software.
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.
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.
Programmer readable, not user readable. It's far easier to learn what it means by just looking at an example than by reading some abstract documentation as you would have to with binary data or some home-made format.
What you want is something like Relaxed JSON (http://www.relaxedjson.org/), but it's not valid JS, while JSON5 is.
Yaml is kind of readable, but god help you if you have to write it
I enjoy using json5. I solves a real problem imo..
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.
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.
> I enjoy using json5. I solves a real problem imo..
And what problem would that be?
And what problem would that be?
If you don't know then why are you commenting? Go read the Readme, and stop talking smack about other people's projects when you don't know such basic details.
Having a tolerable experience when forced to hand-write JSON?
Same one that HTML7 solves.
Perhaps the fact that it's popular is exactly what those nay-sayers were worried about. They didn't want a more fragmented world of incompatible standards.
Some appealed to unrealistic things though, like “all decent text editors should help to make json typing/formatting bearable instead”. Yeah, that totally worked before and will work this time too. We’d all do much better if our standard formats weren’t such an annoyance to work with in the name of something that computers wouldn’t even notice eventually. If there is a void inside a busy place, it will be filled regardless. With that in mind, think what would happen if something much less adequate filled that void. They didn’t want world which couldn’t care less about how anyone wanted it to be. But that’s what we can only have.
I don't think ignore the haters is sage advice in this context. What was directed at this project in the original HN thread was not hate, it was criticism. These are very different things. People were not abusing the author. Some of the original commenters had very salient critiques, and questions.
"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.
"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.
The criticism highlighted in the article looks more like hate than criticism, to me.
Does ‘downloads per day’ actually mean anything? It could be someone large company’s CI system building on every commit.
I don’t think I’ve ever seen a JSON5 file in the wild.
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.
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.
Although I cannot assume, I'd at least hope that a "large company’s CI system" would cache the frequently encountered version(s) of a certain dependency :/
Not a safe assumption. They tend to only invest effort into caching after getting blocked.
As a concretr example, this is a common big problem for NPM, and they have to resort to blocking IPs and/or CIDR ranges.
As a concretr example, this is a common big problem for NPM, and they have to resort to blocking IPs and/or CIDR ranges.
Does ‘downloads per day’ actually mean anything? It could be someone large company’s CI system building on every commit.
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 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.
Maybe 2 or 3 big companies.
I'll never understand why those companies can't bother to set up an internal mirror.
I'll never understand why those companies can't bother to set up an internal mirror.
"The ‘be lenient in what you accept’ philosophy is a disaster" - I've seen that stated before, and I don't think I quite agree. It depends on how much market power you have - if you're Chrome or Safari, I agree, you should display non-compliant pages in a way that makes it obvious that they're broken.
But if you're just developing a backend component that happens to consume data in a particular format and it's not part of a system that millions depend on daily, ensuring it can handle non-strictly-conforming input well usually pays off (but by all means, do what you can to warn relevant users).
CI like that can give you some boost, but if the project is building many times a day, the dependencies are cached somewhere. Otherwise people get too annoyed with delays. There may be a phase of lots of downloads, but then it gets fixed.
I think most companies do not set up mirrors. There is no way millions of individual companies are downloading daily the same pieces of code. And if they had caching they'd download them only when a new release happens, not daily.
There aren't that many companies in the world basically.
There aren't that many companies in the world basically.
You don't have to set up local mirrors. You can start the build with periodically-saved node_packages, or if you're using docker "ADD packages.json, RUN npm install", or commit vendored modules, or do one of thousand of other things.
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.
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.
Yes you CAN do all of these things, but do people do them?
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.
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 you CAN do all of these things, but do people do them?
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.
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.
Valid question, the article has a footer
> JSON5 is in the top 500 by both dependents and PageRank
that probably confirms the project is significant but doesn't answer your question.
> JSON5 is in the top 500 by both dependents and PageRank
that probably confirms the project is significant but doesn't answer your question.
If you had OpenAPI to document the JSON, where would you use comments in the JSON payload?
Why would you assume that you would?
If you did, I guess it would be anywhere that you had a description in the OpenAPI document. But I wouldn't do that.
If you did, I guess it would be anywhere that you had a description in the OpenAPI document. But I wouldn't do that.
On the other side of this, it's fascinating how often people fall susceptible to arguing why something should or shouldn't exist for someone else, rather than just making a limited statement about utility for themselves. Something to stay cognizant of, this article is a good lesson on empathy!
Not everything is about yourself. And once everyone is using some terrible format you won't be able to avoid it anyway.
Json comments is something I always wanted, for json files with data that you need. I even use regexp to remove them in some cases (where I know it won't conflict with the strings themselves).
Didn't knew about this json5 thing but I'll try to use it instead.
Didn't knew about this json5 thing but I'll try to use it instead.
If you just want comments (and trailing commas), there is also this: https://www.npmjs.com/package/jsonc-parser
Phew, when I read these posts, I often wonder if I said something dumb in the past and I think I can easily be proud of my comments there, though I missed the JSON5 thing[0]. Fortunately, the thing that keeps me from saying dumb shit about other peoples' tech is:
* 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...
* 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...
Regardless of JSON5, I realized it's just not constructive to tell someone why something they made will fail. It would be great if you could tell them how to prevent failure, but just portenting it serves nothing.
I'll take any feedback. If someone tells me I'm dumb and have it wrong, I thank them and fix it. Now they can't complain about it, I learned something, and someone spent their time giving me free advice.
But if they don't convince me I'm wrong, then I ignore them. :)
But if they don't convince me I'm wrong, then I ignore them. :)
> 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)
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)
(Sorry for the late reply.)
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.
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.
> If the argument is compelling and cogent, people listen.
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)
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)
I can really relate to this. I posted something earlier this year about how a number of file system problems are directly related to an archaic architecture that was designed when hard drive capacities were measure in MBs. I offered a possible solution in a hobby project that I have been working on for years.
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.
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.
I read through most of those comments and while a lot of them are critical or negative I would still say most of them are "good" as in that they are constructive and give feedback on the idea or it's execution.
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.
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.
I took another look at the HN comments and I think you are right, there were a lot more constructive comments there. I guess I just remembered the toxic comments on Slashdot a lot more and mixed the two in my memory.
> I just remembered the toxic comments
We tend to pay more attention to the negative and dangerous -- a survival thing, right (from when we were hunters and gatherers)
We tend to pay more attention to the negative and dangerous -- a survival thing, right (from when we were hunters and gatherers)
>(BTW: the comments on HN were much more civil than on Slashdot where the story also got picked up)
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.
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.
I don’t remember the Slashdot comments ever being valuable. It was flooded with troll comments, and once you got past the troll comments, there were low-effort jokes, “first”, etc. Dig through the Internet Archive and you’ll see old Slashdot comments in all their glorious mediocrity.
Or search for “gnaa”, but not if you’re on a corporate network.
Or search for “gnaa”, but not if you’re on a corporate network.
Maybe I'm wearing rose-tinted glasses, but I remember Slashdot comments being full of highly insightful and informative comments back in the early 2000s.
Insightful comments, long ago. Yes wasn't it a bit like HN is today, back that long ago
JSON5 isn’t a crazy language. Just used some productions from ECMAScript spec that is already part of JS. Anyone familiar with JS should pick up JSON5 quite easily.
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 believe VSCode uses json5 with .json extension for a whole bunch of their configs.
It would be a slower parser than JSON though.
In videogames, "If there are enemies ahead of you, then you are going the right now."
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..."
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..."
That's a terrible outlook. You are saying that all negative feedback should be ignored by everybody and treated as a positive sign. This is insane.
Nowhere, not once, did I say that all negative feedback should be ignored. I specifically stated "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."
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.
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.
A different but similar saying could be:
"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)
"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)
You could be getting hate with vehemence because you are doing something genuinely hurtful to society, or wrong, or illegal. You said that "if most of the audience [...] universally hates something, [...] you are probably doing the right thing". I restated it a little bit earlier, but surely you see how overly generic your statement is?
What is even the point of soliciting feedback if you will take a universally negative response as a positive?
What is even the point of soliciting feedback if you will take a universally negative response as a positive?
"Horrible. There's a reason JSON is homoiconic with valid javascript." is a weird comment to read about something that takes JSON closer to javascript.
Looks great! Please add an unambiguous timestamp type :-)
If you get it added to javascript, then it will likely get added to JSON5 or a successor. Otherwise that's out of scope.
Javascript has a timestamp type, Date.
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:
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") }This is the first I've heard of JSON5. I can't say my reaction is any different today.
Keep it simple.
Keep it simple.
I remember the original thread and agreeing about the comments addition. I still think it's a poor addition. That said the meanness is disappointing. Congrats to the author for persevering.
Glad to see basic common sense winning out. Crockford was too strident about defending his spec. These are minimal changes that sensible developers find useful in their daily work.
I integrated json5 into a project I regularly use. JSON5 saved a significant amount of ongoing debugging. I appreciate the efforts that went into the project. Thank you.
I really like json5’s comments support, especially when json is used for configuration files so you can explain specific confit without needing to do it in a separate file
[deleted]
I don't think writing an article about hackernews comments from two years ago is exactly what I'd call a lesson in ignoring the haters, but this reads a little bit like someone writing an article about the roaring success of null references after their adoption.
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
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
From my experience, the current generation of programmers value convenience beyond everything else, with a great margin.
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.
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.
I don’t think this is in any way specific to the current generation of programmers.
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.
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.
Performance is a relatively minor problem here, complexity being the bigger concern. For example, I really love all-in-one programs like Rust's 'cargo' and Nix's 'nix', but the work that goes into making them work properly is astronomical. On top of that, both of those programs have limited composability and fight for dominance with other interlocking tools like rustc and nix-env, respectively.
My sense is that it takes a lot of savvy to make good decisions about the complexity of your design and the choices about which dependencies you rely on. This takes years of practical experience to learn, and the incoming generation of programmers will always be bad at it.
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.
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.
However, both sides need a good mentor that shows The Way to them, or just they tend to get stuck where they have started for a longer time than they should, IME.
Of course premature optimization is root of all evil, but JSON is a data exchange format above all else, and using a more relaxed version of it will inevitably incur a higher overhead, and its original format is just native to the language itself.
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.
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.
My assumption here is that, like you, other people will continue to use strict JSON for APIs and interchange, and use JSON5 for configuration as appropriate.
That’s my hope too. In fact the idea is very neat, but it involves humans. So I’ll just observe. :)
This might be a preference revealed in which libraries people choose but I think it is not really exhibited in the kind of libraries or code that people write. You aren’t seeing the vast majority of libraries that aren’t convenient because they don’t get released as open source or become popular.
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.
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.
> 'Popular', 'Easy to adopt' and 'a very bad idea'
is-odd
is-odd
Ten years?
He is ignoring the haters. He continued despite their comments. He is mindful that the haters exist (which you have to be, in order to ignore them), but is ignoring them with respect to the advice they offer.
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.
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.
I don't use autocorrect, I find it does more harm than good. I do use a spellcheck to highlight "errors", but it's then up to me what action to take (and often the answer is that it was't an error at all).
[deleted]
I'm kind of appalled that the Hashicorp guy went that far to put someone down for just building something they found useful to themselves. What a great way to discourage someone from expressing themselves creatively. Glad Aseem carried on regardless.
I regret it! As Aseem said, I admitted fault and apologized for this. Here is an excerpt from an email I sent Aseem when he approached me about it (as he noted in his post).
> 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!
> 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!
I wouldn't want to work for some company whose founder can be openly toxic against a project that solves an actual problem.
How many years ago was this? I’m sure Mitchell has grown a lot and matured since then. Just like everybody else. He did something a little mean spirited. Maybe even something he regrets now. I think he deserves a little bit of grace.
I was 21 years old at the time. What I did was mean, I did apologize, I do regret it, and I don't think I would act this way anymore (to be fair to Aseem, he noted all this in his post). I went through various phases of my life where I was "a little mean spirited" and this is an example of it. Life lessons have changed me over time, but you can catch glimpses of it in moments like this.
More details in this comment: https://news.ycombinator.com/item?id=32380944
More details in this comment: https://news.ycombinator.com/item?id=32380944
An apology is powerful leadership. The resolution I've seen, slinking away as if it never happened, is pure cowardice.
Perhaps he's jealous as half of Hashicorp's portfolio only create more problems than you had originally...
This comment seems to be an example of the exact toxic mentality the author was complaining about.
Like Hashicorp products or not, the remark seems a bit petty.
Like Hashicorp products or not, the remark seems a bit petty.
Umm you can find burning trash in your backyard useful to yourself - but it's still polluting the neighborhood (eg. people using this crap in APIs or pulling down useless dependencies to get this). It's especially bad if you start promoting your practices and get your neighbors start doing this as well.
I completely understand the reaction and find his repo a very appropriate response.
I completely understand the reaction and find his repo a very appropriate response.
This is a great example of how argument by analogy completely breaks down and just helps the author express their feelings.
But for a second it makes them feel smart.
But for a second it makes them feel smart.
Maybe expressing feelings about the topic, as a guess behind the motivation for the mocking repo, was my intention ? (like I said in the second part of the post)
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.
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.
Why do you feel it will sneak in malicious code?
I'm pretty sure the reaction was caused by project's name and had nothing to do with discouraging creativity. If it actually presented itself as "something someone build because they found it useful to themselves", the HTML7 joke wouldn't make any sense at all.
[deleted]
Let me give you a data point from a neutral perspective (I have never heard of you or JSON5).
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.
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.
I wrote a python library.
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.
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.
> I don't remember Mozart or Einstein lament about their haters.
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-...
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-...
[deleted]
The kind of people who leave criticism on HN are not worth listening to anyway. Most of the users of this site have no taste and think they're more brilliant / important than they actually are.
Your comment is so self aware, it's almost an AI. :D
I think you will find that a great diversity of minds are attracted to this site, and for reasons you may not have considered. Curiosity is a giddy thing, and it is a fundamental part of what draws me here. If you read this site and see only the occasional jerk rather than the experience-driven insights, that is your misfortune. Maybe instagram is your thing. I hear they have a lot of cat pictures.
What makes you think the jerks are only occasional?
I've been reading this site fairly regularly since 2010. Not as long as many, but long enough to feel confident saying that though the cast is always changing, this site remains one of my favorite places to
1. discover things I hadn't considered previously
2. reevaluate my past decisions in a way that makes me thoughtful about future ones
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.
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.
Speaking as a reconstructed jerk, I have worked hard at not being one but sometimes it slips through the net.
> ...not worth listening to anyway...
> ...Most of the users of this site...
> ...think they're more brilliant...
I suppose the above critiques are not directed at yourself?
> ...Most of the users of this site...
> ...think they're more brilliant...
I suppose the above critiques are not directed at yourself?
Given you're leaving a criticism on HN, I infer from your own comment you're not worth listening to.
Nice use of recursion ;-)
There's a lot of critics, then you look at their accomplishments and it's unsurprisingly sparse.
Some people get paid in money and not exposure.
You may want to find other employment if your work requires an NDA that disallows any discussion of your work, or your future opportunities to get paid in money may be limited.
They aren't. National security is like catnip for recruiters.
As someone on HN, I can't say with confidence that I resemble that remark.
But do they shave themselves?
rofl
I'm really puzzled by "JSON is for machines, not for humans" types of comments here. FFS, JSON has whitespaces, that alone should answer who it was made for. And making human-readable formats more human-readable is a good thing. JSON5 is awesome.
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.
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.
[deleted]
Here's the old (2012) HN thread with the haters in it: https://news.ycombinator.com/item?id=4031699 . Happy to see an old (positive) comment of my own that I had forgotten about, which I think sums the whole thing up quite well. It still applies, so I'll repost it here:
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.
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.
Actually, I found this enlightening. It didn’t reduce the signal to noise ratio in any way.
The comment would have been no less enlightening if just linked. Additionally, this whole thing is just made of pure noise - someone's taking some sort of bizarre victory lap over some slight they feel HN inflicted upon them... 10 years ago.
I’ve thought about it, and you are probably mostly roght, though I don’t think the poster was trying to take a “victory lap around anyone.
[deleted]
the general attitude of the critics is correct. the name you chose has implications that are not true - JSON5 has nothing to do with JSON and you have nothing to do with the people who came up with JSON. have you named it something else, you'd receive far less (if any) negative comments.
[deleted]
I still don't get what the point of json is. If you want to dump raw JS data structures as text just do. You don't need a spec or special tools. If you want human readable XML just use s-expressions. Something that's so easy to parse you can roll your own in an afternoon.
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.
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.
"s-expressions" is vaporware. Everyone who says it has a slightly different format in mind. It's easy to be all things to all people when you don't have to actually implement anything.
Every lisp program supports that serialization format out of the box.
No, every lisp program supports its own idiosyncratic variation on it, no two alike.
Yes, just how no two json implementations support the same schema.
Independent JSON implementations can parse and manipulate the same files, since they agree on what the basic datatypes are. S-expression implementations don't; often they don't even agree on what the quoting convention is.
>since they agree on what the basic datatypes are
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.
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.
> That is not the job of the data format, that is the job of the meta data format.
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.
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.
>In theory maybe. In practice it's really nice that all JSON documents have the same standard handful of basic datatypes (number, string, etc.).
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.
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.
> But tell me more about how you can guess the type of 1515151515151 without context.
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.
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.
Shockingly about 98% of the population doesn't find massive mounds of nested parens especially readable.
But massive mounds of </this_tag></that_tag></the_other_tag></yet_another_tag> is readable?
I mean, I guess you know what each tag is closing, which is more than you get with ))))...
I mean, I guess you know what each tag is closing, which is more than you get with ))))...
It kind of is, actually.
But make the brackets curly and it's fine.
Curly bracket languages don't require braces around every statement.
If C was written like
If C was written like
{if {x == 1}{
{return {x + 1};}
}
That's nice, but we're not talking about con, we're talking about json.
Also your syntax is terrible. There are already s-expression versions of c:
Also your syntax is terrible. There are already s-expression versions of c:
(if (== x 1)
(return (+ x 1)))No, these goals aren't mutually exclusive and I am not sure where "shoot myself in the foot" fits here. It's a serialization format and has many practical use cases. At least back your claims with concrete examples.
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?
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?
You're posting this in a thread about json5. Clearly there isn't just one json standard.
If I wanted to dump raw JS data structures as text the most straightforward way I can think of is `JSON.stringify` and `JSON.parse`. No need to roll your own S-expression parser.
console.log(a)
eval(a)
eval(a)
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.