4 ms·

Enjoyed this, as with most of Hillel Wayne's writing. One bit that puzzled me: > “Representation” is similar to mimicry, except it’s about encoding a data str

Enjoyed this, as with most of Hillel Wayne's writing. One bit that puzzled me: > “Representation” is similar to mimicry, except it’s about encoding a data structure in primitives that aren’t well-suited to it. Examples would be representing a tree in SQL tables, representing a matrix with nested arrays, or representing a graph in json. I can see the first two exampples (tree in SQL, matrix as nested arrays) because there are limitations in the representation. The last one though (graph in json) doesn't seem obviously limited. Mathematically, a graph G=(V, E), i.e. a set V of vertices (nodes) and a set E of edges between nodes. That has a direct translation into json: { "G": { "V": ["v1", "v2", "v3"], "E": [["v1", "v2"], ["v1", "v3"]] } } Perhaps it's that each edge is encoded as a list? Or that lists aren't sets, so there might be duplicates? Enlightenment appreciated. -- EDIT: fixed typo.

rzzzt 4y ago
They are probably alluding to the tree-like structure of JSON where you can't represent cycles without inventing a pointer + identifier format first, and that is indeed not part of the building blocks "JSON-the-language" itself provides. This seems to be a direct continuation of the SQL example -- wouldn't you be able to represent a tree with eg. tree paths stored for each item?
tomwojcik 4y ago
Emphasis on "aren’t well-suited to it", I guess. It gets complicated once you want to parameterize each node. For the past year or so I've been "typing graphs" into YAMLs. It's definitely doable, but hard to follow, especially with cyclic graphs. N8N is a very popular nocode workflow builder with a great UI. They store workflows (graphs) as JSON. I use this complicated workflow https://n8n.io/workflows/1534-back-up-your-n8n-workflows-to-github/ https://n8n.io/workflows/1534-back-up-your-n8n-workflows-to-... in my homelab but I can't find a public JSON representation of it. It'd be a great example of how to present a complicated graph. I'll add it as an edit if I find it. EDIT: I found one public workflow backup on github. https://raw.githubusercontent.com/thethanghn/n8n-workflows/deedfa975faf6e31a2c733bc60291d6688db28a8/workflows/Back%20Up%20Your%20n8n%20Workflows%20To%20Github.json https://raw.githubusercontent.com/thethanghn/n8n-workflows/d... It's not that bad.
enriquto 4y ago
> That has a direct translation into json: Sure, but this representation is horrific, and a very clear example of why json is not the appropriate format to store graphs. A more natural format for graphs would replace your punctuation-ridden monstrosity with a simple text file, for example: v1 v2 v1 v3
- spinningslate 4y ago
  I take your point, though you're not directly comparing like with like. I'd used a literal translation of (V, E) so listed vertices explicitly as well as edges. Using implicit representation (as you have), the json could be simplified to [["v1", "v2"], ["v1", "v3"]]. Still more syntax, definitely. But not far off, for example, the graphviz[0] equivalent in syntax overhead terms: graph { v1 -- v2; v1 -- v3; } To be clear, I'm no apologist for json. It just seemed to me there was a pretty direct representation. @rzzzt's observation on json being predominantly hierarchical and therefore tree-shaped seems like the most likely reason behond the original statement. -- [0] http://graphviz.org/ http://graphviz.org/

rzzzt 4y ago

They are probably alluding to the tree-like structure of JSON where you can't represent cycles without inventing a pointer + identifier format first, and that is indeed not part of the building blocks "JSON-the-language" itself provides. This seems to be a direct continuation of the SQL example -- wouldn't you be able to represent a tree with eg. tree paths stored for each item?

tomwojcik 4y ago

Emphasis on "aren’t well-suited to it", I guess. It gets complicated once you want to parameterize each node. For the past year or so I've been "typing graphs" into YAMLs. It's definitely doable, but hard to follow, especially with cyclic graphs. N8N is a very popular nocode workflow builder with a great UI. They store workflows (graphs) as JSON. I use this complicated workflow https://n8n.io/workflows/1534-back-up-your-n8n-workflows-to-github/ https://n8n.io/workflows/1534-back-up-your-n8n-workflows-to-... in my homelab but I can't find a public JSON representation of it. It'd be a great example of how to present a complicated graph. I'll add it as an edit if I find it. EDIT: I found one public workflow backup on github. https://raw.githubusercontent.com/thethanghn/n8n-workflows/deedfa975faf6e31a2c733bc60291d6688db28a8/workflows/Back%20Up%20Your%20n8n%20Workflows%20To%20Github.json https://raw.githubusercontent.com/thethanghn/n8n-workflows/d... It's not that bad.

enriquto 4y ago

> That has a direct translation into json: Sure, but this representation is horrific, and a very clear example of why json is not the appropriate format to store graphs. A more natural format for graphs would replace your punctuation-ridden monstrosity with a simple text file, for example: v1 v2 v1 v3

spinningslate 4y ago
I take your point, though you're not directly comparing like with like. I'd used a literal translation of (V, E) so listed vertices explicitly as well as edges. Using implicit representation (as you have), the json could be simplified to [["v1", "v2"], ["v1", "v3"]]. Still more syntax, definitely. But not far off, for example, the graphviz[0] equivalent in syntax overhead terms: graph { v1 -- v2; v1 -- v3; } To be clear, I'm no apologist for json. It just seemed to me there was a pretty direct representation. @rzzzt's observation on json being predominantly hierarchical and therefore tree-shaped seems like the most likely reason behond the original statement. -- [0] http://graphviz.org/ http://graphviz.org/