There may be a tiny bit of signal in such comments but it's mostly just noise. I try to just ignore any comment that looks like the commenter just wrote whatever came to their mind, they're gonna forget about it in 10 seconds too when they're off to the next thing to react to.
JSON is useful partially because it’s easy to parse, so parsers already exist in every language. Extending the syntax is undoing all the communal work, and encroaching on grounds that YAML and other languages already cover.
> Extending the syntax is undoing all the communal work
JSON5 takes stuff from ES5.1 and adds it to JSON, and ES5 is backwards-compatible with older JS. This means it's fairly trivial to convert JSON5 to JSON (literally 13 lines: https://gist.github.com/iddan/3d34b12f6b22c30a8a07c149b3175e...). And ES5.1 itself was the product of communal work.
> encroaching on grounds that YAML and other languages already cover.
I don't know that we should really start dividing features into nice little boxes so no one steps on each other's toes. Trying different solutions for the same problem can eventually bring us more optimal solutions than if we just sat around twiddling our thumbs because 'it's been done'. It's not like there's an army knocking on your door going "switch to JSON5 or we'll kick your teeth in." People can stick with what they want to do on the merits, but I don't see that as a reason to shut down others' work.
Since this behavior is so common, apparently it works, evolutionary:
It makes others think your are smart, for a long while
And not much effort required, on your part. So, a great opportunity?
And the more popular the project you start bashing is, the smarter you'll seem? Corollary: If one builds something great, one will get dissed by some.
Also, I think it’s very poor character to say on one hand that people’s reaction doesn’t bother them and dedicate a third to a half of the article to Mitchell’s criticism specifically. I think Mitchell’s criticism is completely reasonable (I remember this as an era of “solving json” through multiple alternative formats) and drawing attention to what seems in retrospect as a mean-spirited act is actually quite a cynical attempt to strip the context of it and deliberately cast Mitchell in a poor light. Mitchell’s intention is very clearly a technically minded one to nudge people away from trying to massage long term, durable standards in often trivial, subjective ways with an end goal that can only result in format thrashing that doesn’t ever address anything substantial.
Additionally in terms of the criticism, I observe the inverse phenomena to what you describe. You say that popularity isn’t a good indicator of goodness, but I think the inverse is goodness isn’t an indicator of eventual popularity. Some very elegant solutions just aren’t flexible enough for the real world. It is short sighted to try to argue some objective definition of badness because it doesn’t solve a problem you have or doesn’t fit your version of what a product like that should be. Sometimes in the absence of perfection people just have to get work done and want tools that make that easier.
I think that’s the sleight of hand occurring right, it’s reasonable to say he might mot have linked to it, but the purpose of the repo was not to shame the author. It might be my own predilection, but it strikes me as dishonest to say “I didn’t mind this” and then imply the opposite.
> Additionally …
Right, me too, they both occur. I don’t think I actually specified an argument as to why json5 is bad or even argued that it was. My comment is mainly about the article itself.
This whole paragraph reads as an argument to not use json5 given that it is very much trying to perfect the imperfect json, which most people just get on with.
https://github.com/babel/babel/blob/b1e73d6f961065c56427ffa8...
https://nigeltao.github.io/blog/2021/json-with-commas-commen...
The "Why not JSON5, JSONC #1, HJSON or HOCON instead?" answer says it's because of "unquoted strings", then links to a section that only talks about unquoted values. JSON5 doesn't have unquoted values.
Everything else is a matter of taste, and who really cares.
As long as we're clear that JSON5 never gets a .json extension, what is the problem?
Just adding comments and multi-line strings doesn't make it human-readable, it is still too bloated and I don't like writing it manually. If you want a human-readable format, try at least to remove unnecessary quotes, brackets and commas and make it look similar to YAML.
JSON is not intended to be used in configs and other user-editable files.
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.
Notwithstanding which, I too would prefer to interchange data via S-expressions.
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.
Yes, but it’s a bit late for that.
It sounds like you’re advocating for a configuration format somewhere in the space between JSON and YAML. Not JSON, because it’s annoying to write by hand, no comments, no trailing commas. Not YAML, because of all those unintuitive edge cases like “no” (unquoted) being a Boolean.
It sounds like the primary disagreement here is where in the design space between JSON and YAML is the right syntax for configuration files.
That just shows poor judgement on behalf of the developer who made that decision, not a failing of the language.
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)
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.
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.
This really... doesn't matter. Humans read and write it all the time. If everybody is getting annoyed at it because they're reading it, they have every right to wish it was more human-readable, hence trying to make it so. There's nothing wrong with that.
Regarding the criticism, I get the same bad energy when people get a kick out of fixing someone’s grammar, and then do not even comprehend what is being complicated.
Well done on the lib and thanks for building something useful! Good writeup also! Think I’m going to give the commit access trick a shot.
And what problem would that be?
"Ignore the haters" reads like: "I ignored all criticism of my idea, and some other people like it anyway.".
There's already so many terrible technologies in the web programming domain that have plowed onwards in the face of so much criticism, and now we're stuck with them. Part of being a good programmer is being humble, and accepting that you might not have all the answers, the best ideas, or see the bigger picture.
I’ve always wanted comments in JSON, but the other issues highlighted are not things I care about. The ‘be lenient in what you accept’ philosophy is a disaster, just look at HTTP… stricter is better IMO.
As a concretr example, this is a common big problem for NPM, and they have to resort to blocking IPs and/or CIDR ranges.
I don't think you understand quite how many 60,000,000 downloads per week is if you think a big company's CI pipeline might account for that.
I'll never understand why those companies can't bother to set up an internal mirror.
There aren't that many companies in the world basically.
> 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 did, I guess it would be anywhere that you had a description in the OpenAPI document. But I wouldn't do that.
Didn't knew about this json5 thing but I'll try to use it instead.
* my belief that people who execute on some project are inherently superior - they made a thing to solve a problem! Automatically superior to people who didn't make a thing
* the Blub Paradox http://paulgraham.com/avg.html I can only judge projects accurately where I am operating at a higher-level of thought. If I don't get the need, then I am probably not operating at a higher-level than the author. I prefer to be able to have sufficient Theory of Mind thinking that I can inhabit the author's mind to see why they need something, make the best case for it, and then reject/accept it if I have to. There are many places where I can't. The most trivial example which everyone grasped before I got there is GraphQL as an API specification and IDL, which I only recently really grokked.
In any case, I had a figment of the idea that you talk about which is the "people who won't be your users". Thanks for citing the thought around that.
Congrats and good luck!
0: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
But if they don't convince me I'm wrong, then I ignore them. :)
What if, though, they convince others that you're wrong -- so no one wants to use your software?
(although it would have been helpful to many)
I can post my counterarguments and then the other folks can decide. If the argument is compelling and cogent, people listen.
But I know I'll never convince everyone to like my stuff. The goal is to make a quality, useful product while listening to good suggestions for improvement and not letting people get you down.
https://news.ycombinator.com/item?id=30449263
While there were some really good comments, the vast majority were very negative and critical. (BTW: the comments on HN were much more civil than on Slashdot where the story also got picked up) Still, I didn't ignore the criticism but tried to learn from it and there were some encouraging comments mixed in as well.
When you say "While there were some really good comments, the vast majority were very negative and critical" it sounds like you think that negative or critical comments cannot be good.
Slashdot stopped being a worthwhile place to frequent at least 10 years ago. It's devolved into an utter cesspool, since all the quality people fled for greener pastures ages ago. I recommend ignoring its existence altogether at this point, along with any comments from that site.
Or search for “gnaa”, but not if you’re on a corporate network.
I believe VSCode uses json5 with .json extension for a whole bunch of their configs.
It would be a slower parser than JSON though.
I have long held the belief that if the audience of Reddit or Twitter or Slashdot or Hackernews universally hates something with such vehemance that you doubt your own thoughts then you are probably doing the right thing.
In the words of Casey Neistat, in his video "Do what you can't." - "To the haters, the doubters, my 7th grade vice principal, to everyoneone who has ever anyone with a dream they can't..."
This is not "all negative feedback" or "that it should be ignored by everybody" or "treated as a positive sign" and it is disingenuous of you to imply otherwise or to conflate it as such. I'd like to introduce you to a video between a psychologist and someone with an agenda: "So what you're saying is..." No, that's not what I am saying at all. I cannot decide if you have poor reading comprehension or want to twist someone's words. Perhaps both. I'm done with this discussion with you because I'm not going to engage with someone who suffers from the former or wants to engage in the latter.
Of course what you mean is for javascript to have a timestamp literal. Well, the closest equivalent would be: `new Date("2021-12-17T03:24:00")`
It's cumbersome, but I would accept it:
{ mytimestamp: new Date("2021-12-17T03:24:00") }Keep it simple.
despite popularity, most of the technical comments in that original thread aren't wrong. 'Popular', 'Easy to adopt' and 'a very bad idea' can be overlapping circles, in particular in the world of javascript and npm
This is not wrong per se, but it calls for much more complex code which handles all the edge cases, and hurts performance at the end of the day.
Then, this small performance penalties pile-up and the same developers ask why their code is not working as fast as it should.
I don't call for very pedantic formats, and extremely hand-optimized systems. I just wish there was some more awareness of the trade-off they're making and making small inconvenient, but technically lighter trade-offs, these codebases can obtain very dramatic speedups.
The generation that learned with BASIC or used Smalltalk or Lisp in college is decidedly an older generation at this point.
If performance is important, you profile. Optimizing your configuration format for parsing speed is likely a bad decision unless you’ve identified that it’s a problem.
In my experience, some of the projects which have been most valuable have been those which follow a theme of ‘do something really horrible or annoying inside our program so that the users don’t need to deal with the nastiness’. For example it might mean having to write code with some unpleasant hacks or in a very weird way to fit underlying apis or performance requirements; or it could mean spending a bunch of time manually tuning some heuristics because those heuristics improve the library.
is-odd
The haters were also wrong. They completely misunderstood the needs of the target audience for JSON5. They forgot the world is a messy place, no matter how clean and clear the JSON spec may be, the input from random users may well be messy...
I'm guessing even you simplify your life by using autocorrect and spell check from time to time. Autocorrect has its issues too, it probably makes us lazy and sloppy, but on the whole, it improves the input experience for a lot of users, so on balance, people choose to keep it around.
> 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 completely understand the reaction and find his repo a very appropriate response.
But for a second it makes them feel smart.
These were not haters. They in fact went our of their way to give arguments supporting their verdict, and in some cases even constructive suggestions like "make that a preprocessor instead".
Your piece does not make you look like the smartest guy in the room, vindicated by success and adoring fans. It makes you look like someone who confuses internet fame points with something that actually means something. Like a sore loser who needed to convince themselves that they really are the smartest person in the room.
The internet is a trap. No matter how bad your idea is, you will always find people who think it's great.
Just look how many people Alex Jones found who agreed with his Sandy Hook ideas.
Don't go looking for fans. Go looking for people who disagree, as they will help you improve your skills and grow as a person.
If you were actually as good as you apparently think you are, you wouldn't be wasting time writing text like this. You wouldn't need to. Your work would speak for itself. I don't remember Mozart or Einstein lament about their haters.
Someone online told me another library (released after mine) was doing the same thing.
Turns out other library has very obvious bugs, is 20x times slower, but it has 8x more downloads.
Yep downloads are not a metric of quality.
Can't say for sure about Mozart, although I really would not put it past him to do so.
But here's Beethoven doing the same thing: https://quotepark.com/quotes/2122354-ludwig-van-beethoven-o-...
> ...Most of the users of this site...
> ...think they're more brilliant...
I suppose the above critiques are not directed at yourself?
If the performance of your module suffers from parsing its inputs, you are doing some Really Terrible Thing with your inputs. And if the nature of the task really requires you to parse data quickly and on a big scale, it would be better to ditch JSON altogether and switch to a binary format like protobuf instead.
You know that something has gone very deeply wrong somewhere when people oppose your project because they are ideologically opposed to comments. In my own experience, finding out that many JSON parsers reject comments was a real WTF moment, and a deal breaker for my config-file application, so I ended up using JSON-plus-comments for it instead of JSON. At the same time, lack of support for trailing commas and unquoted member names have been a minor but persistent thorn in my side for no good reason. The justification for not having comments in JSON is that in the great disaster that was XML, some projects would parse the comments and take them as semantically significant. However, the real problem there was that parser libraries would expose the comments, and that some generators would put important information only in comments. But I think that these mistakes are unlikely to be repeated, and that the proposed alternative - moving all comments into the markup, or eliminating them entirely - is just obviously worse.
One of the things that ruined the XML ecosystem was a persistent belief that XML was to be read and written by machines, combined with a reality in which it was mostly used for human-written config files, leading to a tolerance for awful syntax (like prefixing every single attribute with a namespace, and the ridiculous CDATA notation). I'm seeing the same thing with JSON: A significant fraction of its use is for human-written and human-read config files (which often desperately need comments) and people are pretending it's strictly a data interchange format that shouldn't be used for that.
It is sometimes said that JSON was discovered, rather than invented - that the syntax was already out there. So it is with JSON5: There is nothing new in this, it is simply return to JavaScript Object Notation and bringing in the rest of what Javascript has.
So, all you pooh-poohing ideologists: please seriously rethink whether disallowing comments, trailing commas, and quoteless member names is actually a good idea. Consider this in light of the fact that JSON is widely used, today, as a config-file language, and that {"--":"This is a comment"} is ridiculous enough that no one does it in practice, can't be inserted on any line, and invites consumers of your data to parse the comments.
Json is trying to square the circle of "I want things to be easy" but also "I want to not shoot myself in the foot", goals which are mutually exclusive. Every new version of json is just gods way of teaching people how XML got to be the mess it is.
I mean, I guess you know what each tag is closing, which is more than you get with ))))...
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?
eval(a)