About "Everything is a Graph", I tried to design programming languages for graph processing a few year back. The problem here is the "language" part as language always implies sequence (because that is what text is). Sequences of statements just don't cut it. In order to efficiently work with graphs, you need to work in graphs. Thus, it becomes a program graph rather than a programming language. And at that point you run into issues of general tooling. Every single tool ever invented around programming is used in combination with text and sequences.
In retrospective it is funny how everybody implicitly assumes that the next big thing will be yet another programming language. And I am not talking about no-code or AI code synthesis.
The point about Lisp is that, lists aren't just the main data structure: programs themselves are lists. Many years ago, I began developing a language in which programs are directed graphs (http://fmjlang.co.uk/fmj/FMJ.html), and on which I still work when I find the time. One of my aims was to make the language fully homoiconic, like Lisp. The problem I had, and which I've only solved recently, is that directed graphs in mathematics just have vertices and arcs, each of which can be labelled, and that's all, but programs in FMJ have vertices (but with ordered inputs and ordered outputs) and arcs, but also constants and enclosures. So programs are extended directed graphs, and the extensions are only really useful for writing programs. Now I have shown that programs are homeomorphic to directed graphs in the mathematical sense - graphs with just labelled vertices and arcs can be converted to programs and vice-versa. I have also added graph processing primitives, but haven't got much further as I've been busy with other things. I do intend to update my web pages soon, with descriptions of the graph processing and the other features I've added.
After the introduction regarding programs that should be different, etc I expected something innovative but... how is fmjlang different than any lisp? it seems like nothing else than visual polish notation with lisp semantics. Perhaps the "parallel" part is just a different evaluator for a lisp, but I see no other differences to be honest.
FMJ is a statically typed dataflow language. Programs are directed graphs. It has no program counter or stack. There are queues of tagged values at vertex inputs, and vertices execute asynchronously when all their inputs have values with the same tag.
Lisp is a dynamically typed impure functional language. Programs are nested lists. Its interpreter runs by calling eval and apply, which call each other. After compilation, code runs on a machine with a program counter and stack.
I don't see much similarity myself, and I wrote FMJ and know Lisp well.
Most APLs work just fine with n-dimensional arrays, even though the language only lets you write 1-dimensional array literals. So in practice, we write 1-dimensional arrays and reshape them as needed.
My point is just because you use a sequence-based input method (a programming language) doesn't mean you can't express structured data.
For example jq[1] does a decent job of expressing queries and transformations on JSON (JSON data are trees rather than arbitrary graphs). But trees are a very important type of graph, and I think a language with first-class support for trees would be in a better position to handle arbitrary graphs than a typical programming language.
Hypertext, which is inherently a graph. There's been a lot of tooling (code browsers, IDEs, version control) that's been focused around navigating a codebase as a graph rather than as plain text.
Not totally sure that languages are sequential (they are recursive and Turing complete… although declarative as well).
The actual sequential thing is consequence of states s0, s1, etc and the only deviation form sequence would be another timeline or state that did not produce.
In retrospective it is funny how everybody implicitly assumes that the next big thing will be yet another programming language. And I am not talking about no-code or AI code synthesis.