Hacker News Reader

Comment by larodi | Hacker News Reader

>I’m amazed how much collapses into a single domain: SQL.

perhaps is more correct to say "all data, including code, is table-representable, even though being a graph" or "everything falls back to tables" or even "relational algebra is all u need", but I strongly disagree SQL being a domain on its all, and that it (all) collapses into such domain.

One can collapse segment tables likewise into DATALOG, which is also a PROLOG-derivate. So then the thing demonstrated here is - "all collapses into grammars perhaps". which is not new, but there are plenty of engineering details, and whatnots to consider, to make such model viable for large-scale deployment. And trouble is it is not so easy to infer stuff about grammars before you expound/infer on them.

don't get me wrong - I love SQL, and respect SQLite and DuckDB for what they are. what we see here is one very curious approach and great demonstration.

View on HN

It's interesting how different people fall into different "everything is a hammer" perspectives. I have a bunch of people around who do the same, everything collapses into table-like structures, but personally I always end collapsing everything into a tree, one way or another. Any problem I encounter, my brain seems to just default into "Yeah, arranged this way, this is clearly just a tree", and it keeps happening for stuff.

And for me, tables are just trees, but for them, trees are just tables.

I'm sure you've stumbled upon graphs that are not trees, which can be represented with tables.

But on the other hand table are represented with trees![1]

[1]: https://en.wikipedia.org/wiki/B-tree#B-tree_usage_in_databas...

And those trees are usually represented as tables via an array of structs or similar. IMHO, the architecture of memory and memory access should push us more towards tables as a default data structure than trees.

Everything can be a tree with a single node that stores a blob of the data in whatever format you want.

As long as there are no self loops, then you can represent a graph with a set of spanning trees that cover the edges. This is particularly efficient when using a depth or parent vector tree representation and is seen in HPC applications.

And eventually tis all the same in the end, and in the beginning. To me all is grammars and program states eventually, and recursion, and prolog and all are diffrent perspective of the same concept/phenomenon.

Is there a higher-level abstraction than parametric grammars nagivating program states...?

As a sidenote, it seems think Stephen Wolfram has similar take on things, but like taken to extremes and applied to dynamic systems. His idea is that all that we experience is a byproduct of some ever-unfolding energies governed by parametric rules. Thus Ruliad. Though his thing sounds less plausible than what we (already) have (applied and working) in classic computing.

idk...

btw, table rows ar facts from PROLOG perspective and much of what SQL stands on is PROLOG. the parametric rules with conjunctions part is in the WHERE clause if one ever wonders... took a while for me to figure it out.

p.s. graphs are represented very often by means of tables, relations if u want. trees are graphs. then, on the other hand, we use trees to index table-storages. so the connection/mapping is there all the time.

A tree encodes a mandatory path or navigation to get to some piece of data. But not every piece of knowledge has a "true" path.

Whereas a relation ("table" in its crude form) can be queried and projected into many forms (including as a tree) but with multiple paths to the same data and ensure future uses are not trapped in a mandatory hierarchy. This was Codd's entire discovery and it still holds 50 years later.

Data-oriented programming suggests if you can structure your program as a series of transformations over tables, it'll be fast, but if it's a series of transformations over trees, it'll spend all its time waiting for cache misses.

Something like that was very popular in early 2000 in Tcl community and used at what then considered "scale." I posted a comment here with links: https://news.ycombinator.com/item?id=49445681

Tabular representation is like the RISC for machine code architecture, but for data.

Reply on news.ycombinator.com