3 ms·

I would claim that object oriented languages are a syntax, semantics and type system for graphs. Objects are nodes. Fields are edges. The object graph is the

I would claim that object oriented languages are a syntax, semantics and type system for graphs. Objects are nodes. Fields are edges. The object graph is the heap. So your whole program state is a graph.

gwbas1c 3y ago
I was about to post "Data structures are graphs," but your explanation says it better.
reaperman 3y ago
I think this is a useful model for me personally, and don't want to diminish its potential value to others; I often think of programs as graphs. I think it's interesting to add to the discussion that I'm wary to reduce anything to any particular "Turing-complete concept". Because anything can be represented by anything.
qsort 3y ago
Graphs are such a general concept that if you squint everything is a graph. Your example works just as well with structs and member fields, we don't even need the OO hypothesis.
- pizlonator 3y ago
  C and structs let you write code using whatever paradigm you want. So you can do object graphs. And you can also do closures. And you can do many other things. Lots of things are possible when you just treat memory as bytes and pointers are just integers.
chubot 3y ago
Right, I think that's just what I said the first time this came up: all languages with GC have graphs builtin. (Though C has graphs too. If every node shares the same lifetime, then it's pretty easy to manage. Otherwise it can be pretty painful) And the good news is that you simply use the TYPE SYSTEM to categorize your nodes and edges. Your edges are references to other objects, which are typed. Node can be typed as well. --- Although the original article does get at this -- there are many types of graphs, and some of them can be encoded in a typed object graph. Some of them can't -- you need the equivalent of void* for the edges. Others would need a List[T] for the edges, if the out degree is not fixed. And that only covers directed graphs, etc. Also, it's true that allocating all these tiny objects as GC objects can be very slow, so then you use other representations of graphs, like a list of pairs of node IDs. I don't really think of it as a "missing" data structure, but yeah now I do see how that framing can be useful.
tlb 3y ago
A limitation is that you can only have one such graph in the program. So any graph algorithm that returns a graph, or uses another graph during the computation, doesn't fit.
- boothby 3y ago
  Don't fall for the abstraction! Mathematically speaking, if you have graphs G1 and G2; you can make another graph H with nodes {G1, G2} and edges {(G1, G2)} and nothing goes wrong. You can definitely view your whole operating system as a graph; it doesn't invalidate having a program running which processes graphs.
PaulHoule 3y ago
For that matter it's true about a certain kind of C program. In a civilized language you have run-time typing and introspection and have all the type information so that it is straightforward to look at the program's data structures as a graph. If you are looking at the debug symbols and a copy of the program you can usually figure this graph out but you might need to think about it sometimes.
dustingetz 3y ago
let x = 1; // edge named x let y = f(x); // node named f with input edge x and output edge y

gwbas1c 3y ago

I was about to post "Data structures are graphs," but your explanation says it better.

reaperman 3y ago

I think this is a useful model for me personally, and don't want to diminish its potential value to others; I often think of programs as graphs. I think it's interesting to add to the discussion that I'm wary to reduce anything to any particular "Turing-complete concept". Because anything can be represented by anything.

qsort 3y ago

Graphs are such a general concept that if you squint everything is a graph. Your example works just as well with structs and member fields, we don't even need the OO hypothesis.

pizlonator 3y ago
C and structs let you write code using whatever paradigm you want. So you can do object graphs. And you can also do closures. And you can do many other things. Lots of things are possible when you just treat memory as bytes and pointers are just integers.

chubot 3y ago

Right, I think that's just what I said the first time this came up: all languages with GC have graphs builtin. (Though C has graphs too. If every node shares the same lifetime, then it's pretty easy to manage. Otherwise it can be pretty painful) And the good news is that you simply use the TYPE SYSTEM to categorize your nodes and edges. Your edges are references to other objects, which are typed. Node can be typed as well. --- Although the original article does get at this -- there are many types of graphs, and some of them can be encoded in a typed object graph. Some of them can't -- you need the equivalent of void* for the edges. Others would need a List[T] for the edges, if the out degree is not fixed. And that only covers directed graphs, etc. Also, it's true that allocating all these tiny objects as GC objects can be very slow, so then you use other representations of graphs, like a list of pairs of node IDs. I don't really think of it as a "missing" data structure, but yeah now I do see how that framing can be useful.

tlb 3y ago

A limitation is that you can only have one such graph in the program. So any graph algorithm that returns a graph, or uses another graph during the computation, doesn't fit.

boothby 3y ago
Don't fall for the abstraction! Mathematically speaking, if you have graphs G1 and G2; you can make another graph H with nodes {G1, G2} and edges {(G1, G2)} and nothing goes wrong. You can definitely view your whole operating system as a graph; it doesn't invalidate having a program running which processes graphs.

PaulHoule 3y ago

For that matter it's true about a certain kind of C program. In a civilized language you have run-time typing and introspection and have all the type information so that it is straightforward to look at the program's data structures as a graph. If you are looking at the debug symbols and a copy of the program you can usually figure this graph out but you might need to think about it sometimes.

dustingetz 3y ago

let x = 1; // edge named x let y = f(x); // node named f with input edge x and output edge y