15 ms·

> Yes, Doug Crockford deliberately removed comments from JSON but people keep putting them back in. If we’re going to have comment-enriched JSON (e.g. for human

• Supermancho 6y ago
  > a practice which would have destroyed interoperability A baseless reason is not a compelling reason. Some imagined eventual use is not relevant to the utility and convenience. Interoperability (in this greater undefined sense posited) cannot be maintained via syntax anyway. > stripping comments before handing off the a JSON parser. Putting an extra processing step before use of JSON is impractical.
  • aaron-santos 6y ago
    The base is the part right before that. > I removed comments from JSON because I saw people were using them to hold parsing directives > Putting an extra processing step before use of JSON is impractical. Care to explain?
    • saurik 6y ago
      People want to use JSON as on disk configuration files, and that's where they want the comments and trailing commas. You can either generate the configuration file from another file, which is frankly stupid annoying and leads to repositories with two copies of the same information, or modify the software that reads the configuration file to strip it before handing it to the JSON parser... which clearly "solves the problem" but also begs the question "ok, so what is the format of the actual confirmation file, then?". The answer to that latter question is more important, as the goal would then be to get everyone to standardize around that format, at which point (I guess) "JSON" would be obsolete as no one would use it and everyone would be using the new JSON wrapper format and all implementations would be designed to have a way to read that format... but like, at that point, you are just making a weird semantics argument. I think the core problem is we just have too many of these... like, what happened to JSON5? We need some reason to all rally around a single specific format of "JSON, but with comments and trailing commas (and I will personally request multi-line strings)".
    • Supermancho 6y ago
      > I removed comments from JSON because I saw people were using them to hold parsing directives Java has not been destroyed, nor any other language that uses injected behavior. Ironically, applying parsing directives are basically another tool being run (similar to a linter) so I'm not sure what he's even getting at when suggesting running yet another tool. This just complicates the ecosystem and is part of what makes javascript seem so primitive in use and syntax. Features that are counterproductive for poorly considered reasons.
    • oblio 6y ago
      Simple example. JSON is frequently used for configuration files. Comments break syntax highlighting for JSON. Similar thing if you want to inspect a JSON dump into a file.
• BugsJustFindMe 6y ago
  Crockford regularly displays a stunning degree of tunnel vision. Without a standard format for comments, you have no reason whatsoever to expect the ad-hoc comments in a JSON file made by anyone who isn't you to be styled like JavaScript comments. And if your response is "then everyone needs to use JavaScript-style comments", well, TA-DA, you've just added comments to the spec. You can't have it both ways. > It's imperative that the JWCC author explain what they find lacking in Doug's solution - stripping comments before handing off the a JSON parser If the syntax rules for adding comments are unspecified, then the the syntax rules for what to strip out are unspecified too!
  • ethanwillis 6y ago
    If the rules are unspecified the only thing you wouldn't be able to put in comments are what is specified as JSON syntax. If you add minimal specifications for escape sequences then even that is allowed.
    • BugsJustFindMe 6y ago
      > If you add specifications then Indeed.
  • tshaddox 6y ago
    I wish JSON supported comments, but I don’t really understand your criticism. You say: > Without a standard format for comments, you have no reason whatsoever to expect the ad-hoc comments in a JSON file made by anyone who isn't you to be styled like JavaScript comments. But, since comments are not supported in JSON, you can expect JSON from external sources to contain no comments whatsoever. That’s precisely Crockford’s point: he didn’t want the format to have a comment syntax that works across different parties so that the only way to use comments is internally, i.e. with a custom comment syntax that you strip before interacting with external sources.
    • hn_throwaway_99 6y ago
      I can't believe that anyone who has ever wanted to comment a package.json file could think Crockford's argument is anything but nonsense. The problem is these files are both edited by humans, and by a plethora of tools. Without a standard comment format, it's been a nightmare trying to comment package.json file in a way that doesn't break something in the NPM/Node ecosystem.
• colejohnson66 6y ago
  If I’m going to use “JSON with comments” that I have to run through a preprocessor before parsing, why not just use a language where comments are explicitly allowed (YAML, TOML, etc.)? Crockford’s answer is not a solution. His words can be rewritten as: “you want comments? Use a different language that looks and feels like JSON, but isn’t.” All that does is add confusion. The only reason JSON is as popular as it is is because JavaScript parses it natively (JSON.parse is defined by the JS spec).
  • redisman 6y ago
    > The only reason JSON is as popular I mean I remember using XML for serialization back in the day and how it made we want to kill anyone who was involved in its creation. JSON won because it’s a great and simple standard and yes because it maps 1:1 to js. It was very popular with people who hated js when it came out too - just because of how much better it was than the other options
    • hn_throwaway_99 6y ago
      I think the move from XML to JSON mirrored a lot of the overall switch in the software industry at large from unnecessarily overly complicated "design-by-committee" specs to simple, get-shit-done practicality. (Heck, anyone remember the horror that was the original EJB spec, or god forbid, CORBA?) The rise in scripting languages like Python and JS on the backend is another example of this.
      • enw 6y ago
        And I see this obsession in some people in the industry trying to prematurely optimize every drop in their code, but they don't understand the added complexity results in inefficiency (mostly lost improvement potential) in the long-term.
• ledauphin 6y ago
  the very simple thing lacking in this solution is that sometimes you want to programmatically _add_ comments to (or preserve comments within) some output file format. If they must be stripped before parsing, then it is definitionally impossible to do either of these things. It's not unlike saying "actual code shouldn't allow comments - you can have a separate preprocessor in your non-code file that strips those out." Sure, you could do that, but all your line numbers would be meaningless and everyone would hate the language from day 1.
• Lazare 6y ago
  Given the number of times people have invented and re-invented JSON + comments, I think it's clear there is a demand for JSON + comments, and that Crockford's view that you can solve everything by asking people to manually strip the comments out before parsing the JSON isn't viable.
  • jtdev 6y ago
    Petabytes of JSON formatted data flowing across the internet every second of every day disagree with your assessment.
    • Lazare 6y ago
      And I suppose the vast amounts of XML (still!) flowing across the internet show there's no need for JSON at all, so the real mistake was even inventing JSON? (Also, as gets pointed out every time this topic pops up on HN, including multiple times on the submission already, the main demand isn't people wanting to add comments to the JS flowing across the wire, but to config files sitting on disk. Responding to people saying "feature X would help use case Y" by noting how many people are using it for use case Z even without feature X is logically incoherent.)
      • jtdev 6y ago
        Crockford (and many others) found that the many flaws inherent to XML warranted a new specification, so JSON was born. If you have an issue with JSON, go create your own spec, don’t shit all over the perfectly capable, simple, elegant specification that is JSON.
        • Lazare 6y ago
          > If you have an issue with JSON, go create your own spec And many people have. You're literally posting this in response to someone submitting the new spec they created to solve this. I don't understand what you're trying to argue here.
• coldtea 6y ago
  >Doug not only explains the reason Just because he had a reason to give doesn't mean it wasn't a bad reason. His stated reasoning failed with hindsight. (a) People already do what he thought was preventing (custom parser behavior) by removing comments, (so his choice failed to prevent what he wanted to prevent) (b) people have already created dozens of JSON parser variants that accept comments, because we really want those. And not just some niche devs - Microsoft and dozens of other big companies have tools that accept JSON + dangling commas + extra comments (so his choice was second-guessed and bypassed anyway, just in ad-hoc ways instead of a better universal one). It wasn't his place to define whether we get comments or not based on some potential parser abuse. But he did it, and now we're stuck with that decision...
  • sagonar 6y ago
    I disagree, he has DONE a common data format that works. If you do mod it, for example add comment to the data sent, 99.9% of the people agree, it is no longer JSON.
    • coldtea 6y ago
      Which is neither here, nor there. People still do it, and they still call it JSON. Heck, many JSON parsers, who otherwise work fine with regular JSON still accept it. Even parsers using a different name like JSONC still allude to the JSON connection - and still are an argument that people found a lack in JSON. Etymology/originology never produced much benefit over pragmatic non-prescriptive examination of how people use things. If anything, it helped confused the situation with pedantic objections.
  • rswail 6y ago
    > It wasn't his place to define whether we get comments or not based on some potential parser abuse. But he did it, and now we're stuck with that decision... He was writing the specification, of course it was his place to do so. Who else would be in the right "place" to write his own specification that no one was enforced to use.
• exporectomy 6y ago
  Oh, it's because people were abusing them. I thought it must have been that you can't read a file then write it back out without either losing the comments or having a whole special data structure to store them in.
• willtim 6y ago
  > A new format is a really weird way to go about fixing a problem that already has a solution. Stripping comments before handing off to a JSON parser is not a full solution. For example, if the file has to be augmented with additional data and written out again, the comments would be lost.
  • wruza 6y ago
    Formatting would be lost too (multiple newlines, array formatting, wrap limits, etc), and the order of keys. There are two separate tasks: comment json for a human and ignore that on parse(), and maintain pretty-json with all its usefulness programmatically with parseWithSyntaxStructure(). We shouldn’t mix them into one single problem, because in one case you just want multiple readers (a human and a computer) and in the other you want to rich-edit a human representation on its own.
• virgo_eye 6y ago
  If the solution is to store config in a format with comments and strip them off before handing to JSON, what should that format be? Shouldn't it be formalized? Couldn't JWCC be that format?