Data structures and their relationship cannot express everything.
SQL is not Turing complete if you don’t use CTE to introduce recursion.
And I think that we all agree that SQL is perfect to work on data structures and their relationship.
The original comment is on a completely different level of analysis. I think that if you know about Linus Torvalds, that you will agree that he knows what SQL is and how it differs from a turing-complete language. The point being made is much deeper and philosophical, and makes a lot of sense in complex systems.
I “know” who is Linus Torvalds since when I installed my first Linux distribution on my 386sx 25mhz when I was 14 or so in 1995/6.
I think he is very smart but sometimes I disagree with him and with his harsh way of relating with the rest of the world.
Now, after a useless appeal on authority, would you mind to explain what is wrong with my opinion about data structures and relationships?
I don’t really think that you can do everything just with data structures and relationships.
If you think the opposite than please explain how you can do everything with something not Turing complete.
> I don’t really think that you can do everything just with data structures and relationships.
No, you can't do everything with just data structures. Everyone knows this. 1st-year junior programmer knows this. It's obvious. The original question did not talk about this, you misunderstood the level of analysis it was aiming at.
The fact that SQL is not turing complete is a meaningless truism here, because Linus obviously did not mean that we should all start using SQL instead of C. The point he is making is that data structures are of much bigger importance to get right in order for the program to be good. Not just fast or just maintainable, or just easy to understand. But all of those things and many others.
Try to look at it that way: what isn't a relational table? Any data structure you can make is essentially a tuple of primitive elements. It may point to further data items, but still. Now, put equally shaped tuples in common tables, and you have a database.
Easily represented as a vertices-array and an edges-array. It's conventional to index the (directed) edges to optimize iteration over all edges from a given vertice. If you're being "sloppy", you can also represent edges as vector<vector<int>> (one array of destinations per source). This is more convenient but comes with the slight disadvantage that these arrays are physically separated (for example, you'll need two nested loops instead of only one to iterate over all edges).
At the same way that you can force everything in a deterministic or non deterministic Turing machine, depending from the problem.
But something that is just looking at data and relationships, akin to a relational database, while extremely powerful, can’t solve every problem in the world.
There are much better tools for that.
And they have something more than just data and relationships.
Of course you can force anything in a graph database. But then you have to make special collection objects to iterate over all Foo items in your process. I guess you'll also need some kind of garbage collector.
> Ironically graph databases are way better for describing relations than relational databases.
You can force pretty much every data structure that I know in a table.
That doesn’t mean that you can solve everything with a non Turing complete language.
So, unless I’m badly mistaken, you’ll need something more than data and relationships to solve everything.
