[HN Gopher] Douglas Crockford Is Not Your Dad
___________________________________________________________________
Douglas Crockford Is Not Your Dad
Author : todsacerdoti
Score : 71 points
Date : 2024-12-08 21:00 UTC (2 hours ago)
(HTM) web link (douglascrockfordisnotyourdad.technomancy.us)
(TXT) w3m dump (douglascrockfordisnotyourdad.technomancy.us)
| neallindsay wrote:
| For what it's worth, yaml is JSON that allows comments (and a
| bunch of other syntax).
| recursive wrote:
| And ambiguity. It's too far in the other direction IMO.
| loevborg wrote:
| Tell that to the Norwegians!
| neallindsay wrote:
| no
| jbaber wrote:
| TOML is one-to-one with JSON, except allow comments.
|
| I like JSON lines format where I can strip comment lines out.
| selectnull wrote:
| Just say no to yaml
| teekert wrote:
| I like yaml, easily readable by computers as well as humans
| (without any coding experience even). I don't see the problem
| with it.
| p1necone wrote:
| And is so pedantic about whitespace that you need to
| specifically configure your editor to be able to retain your
| sanity while editing it, no thanks.
| jahnu wrote:
| Significant whitespace owes me many days of my life.
| Hamuko wrote:
| What? Just write it in JSON format.
| cflewis wrote:
| That is _possible_, but in the real world if your team has
| chosen YAML, it's not because they want to write more
| reasonable JSON. They want to write YAML.
| dorfsmay wrote:
| yaml is a superset of JSON, which means that any parser that
| expect yaml will happily consume JSON!
|
| Also JSON + comment that's JSON5.
| r3trohack3r wrote:
| I used to do this frequently. Take a JSON file, add comments,
| and parse it as YAML.
|
| Then I discovered a handful of YAML parsers in various
| languages support code execution on parsing. Which basically
| killed YAML for me.
| neallindsay wrote:
| It's definitely no good for JSON that you don't write
| yourself. But that's not the JSON that you want to write
| comments into.
| kstrauser wrote:
| I appreciate that Python makes you choose between a "full"
| parser and a safe one.
| jgalt212 wrote:
| At least in Python, YAML parsers are orders of magnitude slower
| than JSON parsers.
| tengbretson wrote:
| Using YAML will make you a more spiritually advanced being
| because every time you copy and paste content into a yaml
| document it requires a prayer.
| Group_B wrote:
| I want to blow my brains out every time there is a mysterious
| tab indent in my file
| Animats wrote:
| What comment syntax does he propose? //
| /* ... */ # --
| recursive wrote:
| He didn't propose one. But given the "JS" part of the "JSON"
| acronym, probably only the first two are reasonable.
|
| But the point is, if you are in control of your own parser, you
| can just use any one of those.
| a3w wrote:
| JSON is not JS, says Doug, too. Since he said "any new JSON
| should not new JS or ON in the name, since we claims it is
| not a javascript object notation, in the end. Perhaps since
| JS/ES is changing, and not everything is an object in every
| language that wants to deal with JSON?
| Animats wrote:
| > probably only the first two are reasonable.
|
| Yet YAML, which is somewhat related to JSON, uses
| # This is a comment
|
| I'm neither pro-comment or anti-comment, but I'm all for
| standardized comment syntax to avoid parsing hell.
| xeckr wrote:
| That's basically a new standard. I like it, but getting all JSON
| parsers on board will be tricky if not impossible. Maybe it
| deserves its own name. How about JSONc _(JAYSON-SEE)_?
|
| Edit: I read the fine print on the page after posting this...
| Turns out that I'm not the first to come up with jsonc. The
| author just isn't a huge fan and wants JSON parsers to accept
| comments. Good luck with that!
| vampaz wrote:
| but my user can't write a browser
| NegativeK wrote:
| You don't _have_ to enable Mallett's Law.
| anotheracc88 wrote:
| You can also put JPEG binary data in RSS feeds, send a string of
| emojis for an SSL handshake and stick HTML 1.0 directly in a
| docker image. You can do those things. You can even write tools
| that accept those things.
| model-15-DAV wrote:
| JSON as a data-format should not have comments. JSON as a file-
| format should allow comments. The problem is this conflation
| between the two.
| martin-adams wrote:
| Can I confirm that the reason it's not preferred to have
| comments in data-formats is because it's to be machine read
| only and as such should be as efficient as possible and not
| contain information that wont be used?
|
| Seeing as I can only see the use case as a file format to be
| read/written by humans in the loop, then maybe the conversation
| should be about compiling the file format to a data format for
| compatibility outside of the user tooling.
| ur-whale wrote:
| > is because it's to be machine read only
|
| Why did they bother making it text-only ASCII then ?
| DaiPlusPlus wrote:
| > ASCII
|
| JSON is notable for making UTF-8 encoding a hard
| requirement.
|
| ...which was pretty ballsy back in the mid-2000s. We were
| still fighting with Shift-JIS and Windows-1252. Excel
| didn't add proper support for UTF-8 until depressingly
| recently.
| hinkley wrote:
| Late 90's I had to fix bugs in a shiftJIS implementation.
| And I couldn't read a lick of Japanese. Still can't.
|
| I don't remember when I started pushing for utf-8
| everywhere but it was "early" by most people's standards,
| so I know what you mean.
|
| And one of the things that makes me dislike MySQL is that
| they have a field type called utf-8 that isn't. And they
| didn't fix it, they introduced a new type instead. So
| that footgun was still there for all to trigger. So mad.
| foldr wrote:
| JSON does not require UTF-8 encoding.
| DaiPlusPlus wrote:
| > JSON text exchanged between systems that are not part
| of a closed ecosystem MUST be encoded using UTF-8
|
| https://datatracker.ietf.org/doc/html/rfc8259
| foldr wrote:
| Ah ok, fair enough. This is a more recent (2017)
| clarification of the standard which I hadn't seen. The
| original mid 2000s specification did not require UTF-8.
|
| > Previous specifications of JSON have not required the
| use of UTF-8 when transmitting JSON text. However, the
| vast majority of JSON-based software implementations have
| chosen to use the UTF-8 encoding, to the extent that it
| is the only encoding that achieves interoperability.
| DaiPlusPlus wrote:
| The original spec did require that all JSON decoders
| support UTF-8, though.
| foldr wrote:
| Hmm, not as I read it. It says that UTF-8 is the
| 'default' encoding. In context that just means that it's
| the encoding you assume if the first four octets don't
| match a pattern characteristic of one of the other
| encodings (when restricted to ASCII characters). See
| section 3 of
| https://datatracker.ietf.org/doc/html/rfc4627. The
| original RFC is vague, but I think the idea is that a
| fully conformant implementation would support all the
| encodings mentioned.
| hinkley wrote:
| JSON wins because it can be casually inspected by people
| testing bizarre theories. The importance of this is lost on
| people who don't treat triage as a skill that can be honed.
|
| I like to solve problems - or at least bringing them to me
| doesn't result in a loss of status for either party. People
| notice this about me and bring me problems. Someone
| recently described to people what is essentially my
| process: the likelihood of the cause divided by the
| difficulty of verification. Partially sort and just start
| checking off assumptions.
|
| A lot of cheap but low probability options get shuffled
| higher, and just sending the wrong data is a common enough
| problem, especially with caching. And if it's nearly free
| to look at the payload, it'll get checked. If it isn't
| people will try everything else to avoid it.
| johannes1234321 wrote:
| The argument is that comments are often used as an escape
| hatch from specified formats to carry further instructions.
| So you got a properly specified format and then want to do
| vendor&extensions but not break other implementations ...
| just make your extensions a comment. Then other parsers
| ignore it and you can do your thing.
|
| The idea is that this forces better formats.
|
| How well this works? Well, then I got an "x-comment" property
| or non-standard comments. Nonetheless. If people see the need
| to hack some extension in, they'll find a way.
| Kwpolska wrote:
| The problem is using JSON as a file format in the first place.
| It's not designed for humans to edit. (Then again, it's better
| than the Norway-sceptic YAML.)
| peterashford wrote:
| I disagree. At least in an ought vs is sense: it's entirely
| the kind of format that I would create as an editable format.
| As witnessed by the fact that my workmates and I did create
| very nearly JSON previously as a file format in the 90s (but
| for C code programs)
| Kwpolska wrote:
| For a very narrow target audience (programmers), JSON is
| fine. If you want the file to be edited by anyone else,
| JSON is pain.
| Cthulhu_ wrote:
| But it happens. 'npm install' will edit your json file, but
| so can I.
|
| That said, I don't like it as a config file read/written by
| humans.
| Jare wrote:
| What example(s) of file format would you say are designed for
| humans to edit and still represent the kind of structured
| contents that json does?
| Kwpolska wrote:
| I can't think of anything that is not painful in some way.
| thayne wrote:
| TOML, extensions of json like json5 and hjson, a bunch of
| lesser known formats for nested structures like NestedText,
| UCL, kdl, Eno,sdlang, eldf, etc.
|
| Also languages with some progrommatic capabilities like
| cue, dhall, jsonnet, nickel etc.
|
| Non of them are perfect, and some are less suitable for
| certain use cases than others. But IMO pretty much all of
| them are better for human editing than json, and in many
| cases yaml.
| lolinder wrote:
| But they're not two different formats--they're two different
| jobs being done by the same format.
|
| JSON as currently spec'd is honestly quite bad at _both_ jobs,
| but the most rational defense of its use as a data format is
| that it 's (mostly) human readable. Given that that's its main
| value proposition, what exactly is the reason for saying that
| JSON-as-data-format should not have comments? What do we lose
| if we allow them?
| sophacles wrote:
| I think json should allow comments.
|
| But there are dangers there - look at how horribly comments
| get abused in code:
|
| * doctests are nonsense, just write tests. (doctests like
| rusts that just validate example snippets are the closest
| thing to good I've seen so far, but still make me nervous).
|
| * load bearing comments that code mangling/generation tools
| rely on (see a whole bunch of generated scripts in your linux
| systen - DO NOT EDIT BELOW THIS LINE)
|
| * things like modelines in editors that affect how programs
| interact with the code
|
| * things like html or xml comments that on parsing affect end
| user program logic.
|
| Comments can be abused, and in something like JSON on the
| wire I can see systems which take additional info from the
| comments as part of the primary data input. Often a
| completely different format... and you end up with something
| like the front-matter on your markdown files as found in
| static site generators.
|
| Point being, comments are not a purely benign addition.
| m463 wrote:
| > but the most rational defense of its use as a data format
| is that it's (mostly) human readable
|
| I would call out portability instead, which is not dependent
| on the byte ordering or endianness issues of binary data
| formats.
|
| sort of like: javascript is portable code, json is portable
| data.
| pjc50 wrote:
| The only reason it became popular is that conflation!
| code-faster wrote:
| All you're doing is creating a new spec that's not JSON. JSON has
| no comments. Your spec does. Your parsers handle both specs.
|
| https://xkcd.com/927/ applies
| dorfsmay wrote:
| Another advantage of JSON5 over JSON is that extra comma at the
| end of a list is not an issue.
| vasilvv wrote:
| Isn't this the problem that JSON5 (and probably other similar
| projects) is supposed to solve?
|
| Both JSON (as defined in the RFC) and JSON5 have a nice property
| of being well-defined, meaning that you can use different
| libraries in different languages on different platforms to parse
| them, and expect the same result. "JSON but parser behaves
| reasonably (as defined by the speaker)" does not have this
| property.
| avmich wrote:
| http://seriot.ch/projects/parsing_json.html
|
| "Despite the clarifications they bring, RFC 7159 and 8259
| contain several approximations and leaves many details loosely
| specified."
| hinkley wrote:
| Nothing will probably ever top Markdown in my mind for
| bullshit specifications.
|
| And Gruber wouldn't give Jeff Atwood permission to call his
| variant <something> Markdown, or it seems anybody else, so we
| ended up with CommonMark, and GFM.
|
| Json5 is good for JSON at rest, as others have mentioned
| already.
| dolmen wrote:
| https://json5.org/
| sushidev wrote:
| Lol "If Douglas Crockford actually is your dad then please do not
| read this web site."
| eclectic29 wrote:
| One man's extremely horrible mistake and look how the whole
| industry has been suffering for decades - countless articles
| debating the existence or absence of comments, new formats, new
| parsers, new ways of adding comments, post-processing, etc. What
| a pity!
| fullstackwife wrote:
| and also life of LLMs would be so much easier, all the JSON
| content, so much missing context!
| pavlov wrote:
| It's better than having to deal with the ad hoc out-of-band
| data formats that people would inevitably have stuffed into
| comments if given the opportunity.
|
| Remember how JavaScript used to reside inside a HTML comment?
| eclectic29 wrote:
| Yes, but you expect much better from a seasoned engineer.
| samatman wrote:
| Definitely. It's important that every ad-hoc out-of-band data
| format look "like this"
|
| never // Like this
|
| Bad Things will surely befall us if we break the taboo.
| fkyoureadthedoc wrote:
| Why would a comment be required for this when they can just
| use a string property? YAML has comments, and they are not
| used by any DSL abomination that I'm aware of.
| takluyver wrote:
| Conda package recipes have a preprocessor using "selectors"
| in comments to conditionally exclude certain lines in a
| YAML file. Not that this is particularly more ugly than
| other YAML DSLs, but it has been used.
| lolinder wrote:
| > It's better than having to deal with the ad hoc out-of-band
| data formats that people would inevitably have stuffed into
| comments if given the opportunity.
|
| As has been pointed out multiple times in the thread so far,
| a random string that is ignored by the receiver is
| semantically equivalent to a comment, and people _totally_
| stuff random crap into strings to extend the data format in
| sometimes-horrifying ways. Banning comments doesn 't stop us
| from abusing strings, it just means we don't have a good way
| to indicate that a part of the file should be ignored by the
| parser because it's not actually data.
| suby wrote:
| Should we not allow comments in HTML, then?
|
| There are parsers which allow for comments if one wants, so
| if someone wants to engineer an insane system no one is
| stopping them, provided they can ensure the parser on the
| other end of it.
|
| This is a data format meant to be readable by humans. As
| such, it's natural to want to support things like
| configuration via end-user editing values in the text as a
| use case. Data is occasionally going to need comments to
| explain valid options or add context for people to edit. This
| is a reasonable thing to have.
| pointlessone wrote:
| We should've kept XML.
| m463 wrote:
| There's something to be said for the hard limitations of json
| that made it successful.
|
| Because of that it didn't become XML or YAML or markdown or
| protobufs or *RPC or microsoft config file format or all the
| rest. All those formats have "reasons", but they are harder to
| understand, harder to parse or not as portable or on and on...
|
| (that said, I wouldn't mind comments. JUST comments).
| koolala wrote:
| Whats the comment syntax they want? I didn't see it on the Lua
| page. Is it not on the page?
|
| {"comment" : "This works everywhere doesn't it?"}
| c0balt wrote:
| Json5/jsonc one, so: { "A": 1 //
| Don't remove this important but undocumented value }
| Cthulhu_ wrote:
| Only if you don't also validate JSON schemas.
| ur-whale wrote:
| Wayyyyy before comments, the one thing I'd want to see JSON
| support is effing trailing commas.
| 3eb7988a1663 wrote:
| This one unambiguously seems like a mistake. Is there any steel
| man argument for why an extra comma should not be acceptable?
| Save a byte over the network?
| a3w wrote:
| Ecmascript is changing JS. JSON is old and unchanging. Which
| is an advantage and a disadvantage.
| kstrauser wrote:
| I think that's literally the only argument for it. And if you
| use compression, now you have to waste an extra symbol on `"`
| in addition to `",`, so even that's debatable.
| hinkley wrote:
| " is already a symbol, but for formatted JSON it's more
| likely to be ",\r and "\r
| kstrauser wrote:
| I bet `: "` is more common than a lonely double quote,
| except at the end of a list of quoted values.
|
| Eh, who knows? But I'm skeptical that the omitted comma
| actually saves any space in common situations.
| smitty1e wrote:
| {"comment":"This valid JSON document totally has a comment."}
| oneeyedpigeon wrote:
| char str[] = "That's like saying this is a C comment";
| sgarrity wrote:
| Imagine if he was though...
| tomcam wrote:
| Why am I always the last to find out
| a3w wrote:
| // or /* */ comments?
|
| Doug, please adopt me!
|
| As a file format, just use jsonc or json5, if you want to use
| comments.
| oneeyedpigeon wrote:
| Do the people who think JSON should have comments also think the
| CSV format should have comments?
| dvh wrote:
| If JSON had comments, people would start putting data in comments
| (mostly annotations probably). What will be next? Allow
| apostrophes for strings? Add schemas so that parsing JSON is
| getting blocked by firewall rules? No thanks.
| gwbas1c wrote:
| > Douglas Crockford Is Not Your Dad
|
| No, he's your drunk uncle who sounds smart when you're young.
| When you learn to form opinions of your own, you realize that his
| opinions are worthless hot air.
|
| Many years ago I went to a session where he promoted asynchronous
| Javascript as the "one true way." In the Q&A, I pointed out that
| callbacks made code much harder to read and maintain compared to
| threaded code; and then asked if there was a cleaner way to do
| it.
|
| His answer was quite rude. A few years later, we got the "async"
| keyword, which solved the problem.
| gmiller123456 wrote:
| Everyone already know which xkcd applies to this, right?
| user3939382 wrote:
| Aren't comments already part of JSON5?
___________________________________________________________________
(page generated 2024-12-08 23:00 UTC)