> The success of JSON was totally serendipity. Getting the domain name definitely helped. There are some things that I didn’t do that definitely helped. I didn’t secure any intellectual property protection on it at all. I didn’t get a trademark for the name or for the logo. I didn’t get a copyright for the specification. I didn’t get a patent for the workings of the format. My idea was to make it all as completely free as possible. I don’t even require any kind of notice. No one has to say, “Thank you, Doug, for doing that.” It’s just free for everybody. And I think that definitely helped.
JSON vs. XML
91–100 of 252 posts
Re: JSON vs. XML
#92Earlier quoted context omitted.
Thanks! Crockford's thoughts on actors are really interesting. I tried to pull them apart but I didn't get very far and ended up not including them in the episode. What he is envisioning is not exactly like Erlang but not exactly like Scheme. He said that Carl Hewitt had a lot of ideas and they were hard to unpack. If you're interested though, I would reach out to him. He is very approachable and excited to talk to p…
I do wish some more details about his current thoughts on actors had been included, though I can understand if they were hard to tease out. I would guess that may go back to his work on Electric Communities as E was a message passing system. Would be interested in hearing more of where his mind is on actors today. The closest thing we have right now I think is Spritely Goblins, though that is Scheme. (Not coincidenta…
The design of the language he is (was?) working on is here:
http://www.crockford.com/misty/
There are a few talks from a few months ago on Youtube that detail some of the rationale behind it.
Re: JSON vs. XML
#93What if I hate both formats? XML is overly verbose, while JSON isn't specific enough or precise enough for a lot of my needs. - This message brought to you by TOML gang
Absolutely agree. TOML is far and away the best for config files.
Re: JSON vs. XML
#94I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.
With XML, the complexity is the baseline, and it only goes up from there. With JSON, the complexity is just an option, the baseline is pretty simple. Also, good XML-tools are rare or expensive.
> With XML, the complexity is the baseline, and it only goes up from there. With JSON, the complexity is just an option, the baseline is pretty simple.
Very well put. And we could lower the baseline substantially towards simplicity, even from JSON.
It's pretty clear that a lot of people think this way. Some even seriously try to figure out what such a baseline of simplicity would look like.
There are lots of simple indentation-based designs (similar to YAML) such as NestedText[0], Tree Notation[1], StrictYAML[2], or even @Kuyawa's Dixy[3] linked in this thread.
There seem to be less new ideas based around nested brackets, the way S-expressions are. Over the years, I have developed a few in this space, most notably Jevko[4]. If there ever will be another lowering of the simplicity baseline, I believe something like Jevko is the most sensible next step.
[0] https://nestedtext.org/en/stable/ [1] https://treenotation.org/ [2] https://hitchdev.com/strictyaml/ [3] https://news.ycombinator.com/item?id=35469643 [4] https://jevko.org/
Re: JSON vs. XML
#95I remember one time designing the simplest and most readable data format ever and came up with Dixy [0] after removing all I could and still make it usable I'm leaving it here because it will never be used for anything but at least it may inspire somebody design a better format with simplicity in mind [0] https://github.com/kuyawa/Dixy
This looks a lot like YAML, especially with the non-quoted strings, colons, and indentation. It also seems to share the problems of YAML, namely a very non-uniform syntax. For example, how do you distinguish null (denoted as "?") from a literal string containing one question mark? How do you distinguish the number 1 from the string "1"? Hence why I'm not a fan of both YAML and Dixy.
Other problems to ponder: Is 0 different from 00? Is "1, 2, 3, 4" different from "1,2,3,4"? Is "a: b" different from "a : b" and "a:b"?
Re: JSON vs. XML
#96Earlier quoted context omitted.
> There are no comments, so nobody will try to invent their own meta format or annotations in comments and instead they will put data in the JSON as they should It also means it's worse format for configs where you sometimes need to annotate a few nodes with comments.
For configuration files I add an extra key "_" and a string with the comment as the value. I even add multiple "_" keys to the same object and never seen something break.
This is just a terrible comment format isn't it?
Re: JSON vs. XML
#97For me 3 killer features of JSON are: 1. Parsing JSON doesn't require adding new firewall rules 2. There are no comments, so nobody will try to invent their own meta format or annotations in comments and instead they will put data in the JSON as they should 3. (When compared to JS) someone finally had the balls and picked one type of quotes, this makes making parser so much simpler.
Not supporting comments in JSON was a huge mistake. Yes I'm sure that someone, somewhere has once added comment directives to a file that caused issues. But that's such a rare problem compared to the very real and damaging and annoying problem of not being able to add comments to config files (hello package.json) that it's definitely the wrong choice.
XML supports comments and I have not seen a single use of comment directives in it ever.
I have seen plenty of comment directives in programming languages, HDLs and so on. But they are usually used as hints, e.g. to linters or to control compiler warnings, and they work perfectly well and cause no problems at all in my experience.
You might say that Crockford didn't anticipate JSON being used for config files. Fair enough. But now that it is, it should support comments.
My recommendation is to use JSON5 since it has a distinct file extension and fixes some other things about JSON too (e.g. trailing commas, hex constants) without being full on YAML insane.
Re: JSON vs. XML
#98This quote is funny: Douglas: The first time I saw JavaScript when it was first announced in 1995, I thought it was the stupidest thing I’d ever seen. And partly why I thought that was because they were lying about what it was. A bigger more interesting thing though is how his company failed, in part, because they used hand-rolled JSON for messaging. Douglas: And some of our customers were confused and said, “Well, w…
> I started my career during peak XML crazy and while I liked parts of it at the time, the number of things it was used for was quite insane. I had to maintain a system once where a major part of it was XSLT, when could have just been a simple imperative algo with some config settings. Same here. XML was going to save the world! Remember XML data islands with data embedded in page source and displayed via XSLT? The c…
Nowadays you have the same type of tools, only for YAML. Not sure if that's so much better.
Re: JSON vs. XML
#99Earlier quoted context omitted.
What I appreciate compared to xml is: - generic concepts like arrays and maps - lack of opportunity to invent names Every xml schema is a potential DSL that reinvents things they might now. Other than that it's true that the xml era was just addressing a lot of important stuff early, I guess it was only compatible with big corp mindset and not early web dynamic / fluid / small scale apps. (a bit like how PHP started…
Every JSON schema is also a potential DSL that reinvents everything. Yes, there seems to be some convergence on things, but object arrays in XML aren’t really any more complex than object arrays in JSON — there just might be multiple ways to represent them. For this JSON: { "part_numbers": [1, 2, 3, 4, 5] } You have two main ways to represent these in XML: 1 2 3 4 5 1 2 3 4 5 Is this better than JSON? No, not particu…
Where XML shines is when you pass more complex data types than numbers and strings. If you repeated your example for an array of dates, as an example, strictly speaking you can't even generate the JSON. We'd first have to agree on what string representation of a date we want to use. For XML it's built into the spec.
Re: JSON vs. XML
#100What if I hate both formats? XML is overly verbose, while JSON isn't specific enough or precise enough for a lot of my needs. - This message brought to you by TOML gang
I've got yet another markup language for your hate group's target list :)
Come join the dark side where we enjoy the wonders of binary formats such as avro and protobuf.