|
|
|
|
|
by throwaway_2047
1810 days ago
|
|
Isn't programming itself inherently consist of "graph"? We convert everything into AST after all. The use of abstract concept like currying, recursion, map reduce is to have vocabulary express our thought IMO. Turning into graph is like coding imperatively - hard to grasp from quick glance. Code is more frequently read than written |
|
The article is effectively exploring a way to combine these two methods - to have the code denote a DAG directly (or even cheat a little and denote a graph with cycles), where the runtime representation is also a graph, and not a tree.
Myself, I'm strongly hoping there will be more work done in that direction, because being forced to talk in trees is very limiting. Some problems would be much easier to express as DAGs (or even cyclic graphs), and would even be easier to read them as such.
I worry that what's keeping us working with trees is the nature of plaintext itself. I haven't proven it, or seen it proven, but I strongly suspect that there is no minimal, direct representation of a DAG possible in plaintext - you can't move past a tree without assigning labels for backreferences.