[HN Gopher] Ignore the haters, and other lessons learned from cr...
___________________________________________________________________
Ignore the haters, and other lessons learned from creating JSON5
Author : aseemk
Score : 149 points
Date : 2022-08-07 19:46 UTC (3 hours ago)
(HTM) web link (aseemk.substack.com)
(TXT) w3m dump (aseemk.substack.com)
| dejawu wrote:
| 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.
| moonchrome wrote:
| 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.
| bogota wrote:
| 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.
| moonchrome wrote:
| 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.
| cmdialog wrote:
| [deleted]
| okanat wrote:
| I wouldn't want to work for some company whose founder can be
| openly toxic against a project that solves an actual problem.
| mberning wrote:
| 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.
| iasay wrote:
| Perhaps he's jealous as half of Hashicorp's portfolio only
| create more problems than you had originally...
| PoignardAzur wrote:
| 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.
| furyofantares wrote:
| Non-constructive criticism is extremely easy to produce and can
| make the author of it feel smart for a second. Doing it in a
| place where folks share their creative works is like shooting
| fish in a barrel.
|
| 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.
| vlunkr wrote:
| 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.
| bobthepanda wrote:
| 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.
| didgetmaster wrote:
| 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.
| SahAssar wrote:
| 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.
| pjbk wrote:
| 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.
| thrown_22 wrote:
| 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.
| TylerE wrote:
| Shockingly about 98% of the population doesn't find massive
| mounds of nested parens especially readable.
| AnimalMuppet wrote:
| 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 ))))...
| thrown_22 wrote:
| But make the brackets curly and it's fine.
| TylerE wrote:
| Curly bracket languages don't require braces around every
| statement.
|
| If C was written like {if {x == 1}{
| {return {x + 1};} }
|
| Maybe you'd have a point
| thrown_22 wrote:
| 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: (if (== x
| 1) (return (+ x 1)))
| lmm wrote:
| "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.
| t0astbread wrote:
| 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.
| halayli wrote:
| 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?
| hsbauauvhabzb wrote:
| 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.
| stavros wrote:
| 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.
| Barrin92 wrote:
| 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
| pledg wrote:
| Ten years?
| bayindirh wrote:
| 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.
| dan-robertson wrote:
| 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.
| dietrichepp wrote:
| 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.
| smoldesu wrote:
| 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.
| dietrichepp wrote:
| 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.
| bayindirh wrote:
| 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.
| bayindirh wrote:
| 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.
| dietrichepp wrote:
| 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.
| bayindirh wrote:
| That's my hope too. In fact the idea is very neat, but it
| involves humans. So I'll just observe. :)
| Aperocky wrote:
| > 'Popular', 'Easy to adopt' and 'a very bad idea'
|
| is-odd
| [deleted]
| osrec wrote:
| 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.
| lmm wrote:
| 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).
| gervwyk wrote:
| 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.
| ryscheng wrote:
| 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!
| codedokode wrote:
| 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.
| kryptiskt wrote:
| 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.
| dietrichepp wrote:
| > 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.
| ajkjk wrote:
| > 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.
| cgrealy wrote:
| Because it's really handy to be able to run things like rest
| requests without any tooling more than curl or postman?
| sacrosancty wrote:
| 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.
| userbinator wrote:
| 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.
| orthoxerox wrote:
| What you want is something like Relaxed JSON
| (http://www.relaxedjson.org/), but it's not valid JS, while
| JSON5 is.
| Jare wrote:
| 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)
| LtWorf wrote:
| > 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.
| 11235813213455 wrote:
| 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
| fefe23 wrote:
| 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.
| [deleted]
| LtWorf wrote:
| 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.
| [deleted]
| wdb wrote:
| 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
| throwaway0x7E6 wrote:
| 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]
| TrianguloY wrote:
| 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.
| JoshuaEN wrote:
| If you just want comments (and trailing commas), there is also
| this: https://www.npmjs.com/package/jsonc-parser
| renewiltord wrote:
| 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...
| hnusersarelame wrote:
| 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.
| politelemon wrote:
| As someone on HN, I can't say with confidence that I resemble
| that remark.
| yetanotherloser wrote:
| rofl
| jackblemming wrote:
| There's a lot of critics, then you look at their
| accomplishments and it's unsurprisingly sparse.
| thrown_22 wrote:
| Some people get paid in money and not exposure.
| froderick wrote:
| 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.
| mjmsmith wrote:
| What makes you think the jerks are only occasional?
| froderick wrote:
| 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.
| cmdialog wrote:
| zaat wrote:
| But do they shave themselves?
| pestaa wrote:
| Your comment is so self aware, it's almost an AI. :D
| cassianoleal wrote:
| Given you're leaving a criticism on HN, I infer from your own
| comment you're not worth listening to.
| AnimalMuppet wrote:
| Nice use of recursion ;-)
| wildwildtest wrote:
| 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.
| sacrosancty wrote:
| 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.
| justinlloyd wrote:
| 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..."
| AndriyKunitsyn wrote:
| 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.
| jimrandomh wrote:
| 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.
| [deleted]
| pvg wrote:
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
| stickfigure wrote:
| Looks great! Please add an unambiguous timestamp type :-)
| yawnxyz wrote:
| I love JSON5! My only gripe with it is that I have no idea what
| the "5" means, and I don't think it's documented / alluded to
| anywhere...
| cbarrick wrote:
| The 5 is a reference to ES5
| secondcoming wrote:
| 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.
| abirch wrote:
| If you had OpenAPI to document the JSON, where would you use
| comments in the JSON payload?
| snookerdooker wrote:
| 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 :/
| metadat wrote:
| 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.
| onion2k wrote:
| _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.
| LtWorf wrote:
| Maybe 2 or 3 big companies.
|
| I'll never understand why those companies can't bother to set
| up an internal mirror.
| viraptor wrote:
| 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.
| LtWorf wrote:
| 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.
| wizofaus wrote:
| "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).
___________________________________________________________________
(page generated 2022-08-07 23:00 UTC)