Earlier quoted context omitted.
In theory, order shouldn't matter, right? But I recall seeing this trick for adding comments to json: { "foo": "this is a comment about foo", "foo": "actual value of foo that overwrites the comment" } The trick is that the second value value of foo overwrites the first. But, clearly, sorting would would wreak havoc here (if the value was used in the sort key). ;)
Yes. That is valid JSON. A fun fact about MongoDB is it will actually store that JSON, both duplicate keys. The implication is that whatever MongoDB client you're using, that maps Mongo data to dictionaries/maps, is not capable of representing all valid MongoDB documents. It's important to recognize that Mongo may be storing data your client will not be able to access. I learned this when the Python client was showin…
The Pretty JSON Revolution
151–159 of 159 posts
Re: The Pretty JSON Revolution
#152If you're on a mac or Linux system, you likely have a JSON formatter already installed `python3 -m json.tool somefile.json` or `cat foo.json | python3 -m json.tool` will print it in "one line per node" format. 3.9 introduces a --sort-keys switch for sorted objects also.
I would be a little nervous sorting the keys. I thought it was not too uncommon for parsers to treat them as an alist where order matters. I guess so long as it is a stable sort, no big deal?
Re: The Pretty JSON Revolution
#153Re: The Pretty JSON Revolution
#154Earlier quoted context omitted.
I think you missed the point here -- the great thing about author's "oj" here is that it takes existing document, with any format, and makes it look nice, in a fully automated way and without changing semantics. (I am talking about "Human Style with Colors" here -- this is the cool part, and I don't really expect SEN to take off except to display things on the terminal) That tabular-like alignment was generated autom…
> "oj" here is that it takes existing document, with any format No. It takes JSON only. Which is one format out of 10,000 (though a popular one). > There is clearly the table-like structure It is a directed acyclic graph structure. I won't disagree that perhaps in certain older tools oj may be better in certain situations. But Tree Notation (or more generally 2D/3D languages where positioning is the only thing used f…
Is that iris grammar document in designer a good example? Because it does not really show why is it better than something like SEN or JSON. The text alignment is awkward, and it does not fit well on the screen. The colors are there, but I am not convinced that having keywords be a different colors outweights the ugly formatting. And I am not sure what "secondary notations" are, but I am guessing they are not present in the document?
The idea of the schemas are good. The world could use more editors with context-aware syntax highlighting and auto-completion. However, the data model you have chosen ("TreeNode=tuple(string, list[TreeNode]") doesn't map well to any programming language. And the text serialization you have chosen -- having a single canonical representation that is using whitespace as the only syntax element -- un-nesseary restricts the data that can be represented.
I think switching to a more conventional data model and text serialization will significantly increase uptake of your project, as well as make it more aesthetically pleasant. Because I seriously doubt anyone can call your existing grammar programs "nice looking".
Re: The Pretty JSON Revolution
#155Earlier quoted context omitted.
Yes. That is valid JSON. A fun fact about MongoDB is it will actually store that JSON, both duplicate keys. The implication is that whatever MongoDB client you're using, that maps Mongo data to dictionaries/maps, is not capable of representing all valid MongoDB documents. It's important to recognize that Mongo may be storing data your client will not be able to access. I learned this when the Python client was showin…
I can't reproduce that behaviour on MongoDB 4.2.x using Python and the Shell client.
Re: The Pretty JSON Revolution
#156Earlier quoted context omitted.
Not exactly, unfortunately. The text you cite is in the introduction, which is non-normative. That text talks about the conceptual data model, but that's just to frame the reader's thinking. The normative text has the "real" answer, and the real answer is that it's basically undefined behavior. It starts by saying "The names within an object SHOULD be unique", and then elaborates: An object whose names are all unique…
So basically, "it's a free-for-all, we guarantee absolutely nothing unless you 1) don't generate duplicate keys and 2) the code of your consumer doesn't depend on their ordering".
Re: The Pretty JSON Revolution
#157Earlier quoted context omitted.
> "oj" here is that it takes existing document, with any format No. It takes JSON only. Which is one format out of 10,000 (though a popular one). > There is clearly the table-like structure It is a directed acyclic graph structure. I won't disagree that perhaps in certain older tools oj may be better in certain situations. But Tree Notation (or more generally 2D/3D languages where positioning is the only thing used f…
You keep saying that "Tree Languages are the future" but I don't see any impressive examples of it. Instead, when I look at the examples, I see a rather clunky notation. Is that iris grammar document in designer a good example? Because it does not really show why is it better than something like SEN or JSON. The text alignment is awkward, and it does not fit well on the screen. The colors are there, but I am not conv…
You keep saying that "Tree Languages are the future"
but I don't see any impressive examples of it.
Binary notation as an idea was worked through for ~250
years before we had very impressive examples of it in
computers, so I'm pretty happy with the examples so far
given that I'm ~10 years in, and ~4 years since publication.
So just at a high level the short term game common in the
rest of tech isn't something I'm interested in playing.Beyond what's out there, I've seen the results from thousands of experiments in everything from assemblies to compiler compilers to declarative data notations, and from software to hardware and everything in between, so the amount of data I have dwarfs what everyone else has seen. While I totally get that it's not raining buckets now, and in fact people feel barely a drizzle, I have quite a dataset that there are big clouds on the horizon.
Is that iris grammar document in designer a good example?
It's mildly neat. Here's how we used an early version of
that a couple of years ago to publish synthesized data for a
GWAS EOPEC study
(https://github.com/breckuh/eopegwas/blob/master/mockData/cli...).
Tree Notation will become the standard way to describe data
schemas and make synthesis a breeze. outweights the ugly formatting
The formatting can be described as this: minimal. In fact,
the most minimal. If you think minimal is ugly, than we
probably won't come to an agreement. Keep in mind though
that you can write code to project Tree programs in whatever
way you want. I won't disagree with the statement "Tree
Notation doesn't work as well with my existing tools as
other langs", but if you go back to stuff from 2017 and look
at the trajectory, you'll see that Tree notation tooling has
improved remarkably and in a couple more years you'll see
stuff that just isn't possible with 1-D langs. doesn't map well to any programming language
Do you know Lisp? Tree Notation maps to S-Expressions
without parens. un-nesseary restricts the data that can be represented.
From the paper (2017): "Prediction 1: no structure will be
found that cannot serialize to TN." your existing grammar programs "nice looking".
To each their own. I think in the long run simplicity lasts. Also, the bigger idea isn't Tree Notation, but the idea of 2-D and 3-D languages https://longbets.org/793/Re: The Pretty JSON Revolution
#158Earlier quoted context omitted.
jq is a very nice tool for JSON wrangling available to install on most distros. It also provides key sorting, which is great for diff-ing JSON.
jq is a nice tool. oj is similar in many ways but different in others. jq has it's own proprietary query language while oj uses JSON path. The output options are also different with some overlap. Maybe jq will get a pretty output option after reading the article. :-)