Hello, I am Stefan, software engineer. I have spent most of my career in data warehousing, almost everything from tool making to architecture. I am author of Cubes - former light-weight data warehouse toolkit in Python, now discontinued. Exploring alternative ways of “problem modelling”, especially for the domain complex systems. From engineering perspective that lead me to a curious question: whether “everything is a graph” programming language is feasible and if yes, how it would look like. Currently prototyping a library and a tiny domain specific programming language for modelling and simulation of dynamical systems. (Might release a prototype soon). Happy to be here. Cheers.

Hi :)) I've recently come across a claim that "everything's a graph" languages correspond to "everything's a relation" languages (think variants of SQL or Prolog/Datalog). Maybe you can start with this "conjecture" ;)

Hillel Wayne was talking about this idea on Twitter this week, lots of replies were along that vein. Lots of people were saying "isn't a graph just X", which sort of misses the point, I think. The question is the level of abstraction you want to work at. I'm not convinced SQL gets you there. Lots of room to play with this idea, I think. My personal preference would be that it was in the logical paradigm. But I haven't done any graph work outside of Python, so I don't really know what that would look like. Interested to see, though.

I’ve spent almost 20 years of my career in relational algebra world and I agree with what @Jason Morris says – it is related to the level of abstraction for given problem domain. SQL not the abstraction that I believe is suitable for graph-based problems. It serves its purpose and it serves it well, but those are different kinds of problems to be solved. NB: yes, one can implement graphs within SQL, but that misses the whole problem-question.

CUE is an interesting language that works on a value lattice (a special graph). You can easily make a DSL on top of it, implementing the DSL requires writing Go currently. (CUE is written in Go and has APIs available) Propagator Networks are interesting too, might be related to your interests, and updating knowledge or stated in the graph.

Modeling and simulation is a very underappreciated field of computing IMO, given that computers are such fantastic modelers and simulators! Currently the field is dominated by old-fashioned enterprise software like AnyLogic and academically by Netlogo - not many new developments, besides some on top of existing languages like hash.ai, some libraries in the Python/Julia ecosystems, and https://simlin.com/ which approaches from the system dynamics perspective - stocks and flows. Graphs, and especially networks, are core to system modeling, so I'm curious to see your take on it.

Yay propagator networks @Tony Worm! My favorite aspect is to, for a given network, pass different kinds of data through. If you aren't doing that, then you might as well use a more regular program.

@Stiivi Looking forward to see more of your experiments! I have been eternally dissatisfied with data representations in programming languages. Nice to see someone working in this space.

@Konrad Hinsen What do you think of CUE's type lattice? https://cuelang.org/docs/concepts/logic/

So in CUE what we would normally think of as a value is a type right above bottom? To answer my own question, "A key thing that sets CUE apart from its peer languages is that it merges types and values into a single concept. ... For instance, there is no need for generics and enums, sum types and null coalescing are all the same thing." That's so neat. I've always wanted to see this. https://cuelang.org/docs/about/

values span from bottom to top (any) with everything from types, constraints, and data between. They can even be intermixed and still have order (by subsumption) in the lattice.

@Tony Worm Looks interesting in theory at least. If you take a type to be a set of possible values, then each particular value is just a one-element set and constraints define various other subsets. What I can't see from a quick read of that discussion is how this works out in practice!

https://cuelang.org | https://cuetorials.com There are many ways this manifests in practice, since it touches config & data, which every other program consumes. • https://github.com/dagger/dagger (CI/CD) • https://github.com/grafana/thema (API version fluidity) • https://github.com/hofstadter-io/hof (data model & code gen) • https://github.com/tmm1/taxes.cue (US tax forms)