Stiivi
1 month agoHello, 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.- j
Jan Ruzicka
1 month agoHi 😃) 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" 😉 - j
Jason Morris
1 month agoHillel 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 think visualizations with that sort of language would be easy, and phenomenal.
Stiivi
1 month agoI’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.
Tony Worm
4 weeks agoCUE 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.- r
Riley Stewart
4 weeks agoModeling 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. - w
wtaysom
4 weeks agoYay 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. - I agree with @Jan Ruzicka that it's good to differentiate how doing things with graphs differs from doing things with relations. For me it's the paths that would make for awkward recursive joins when imagined relationally, that and cursors/traversals that, agents living in a graph, that aren't so much a thing when thinking about relations.
Konrad Hinsen
3 weeks ago@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.Tony Worm
3 weeks ago@Konrad Hinsen What do you think of CUE's type lattice? https://cuelang.org/docs/concepts/logic/- w
wtaysom
3 weeks agoSo 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/ Tony Worm
3 weeks agovalues 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.Konrad Hinsen
3 weeks ago@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!Tony Worm
3 weeks agohttps://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)- Most people are using it as a better Yaml to get started
Join thread in Slack
View count: 3