3 ms·

The top-level README gives a bit better idea. Armed with that the explanation might sound a bit more understandable. I'm not familiar with the project (or Cloj

by _flux 7mo ago

The top-level README gives a bit better idea. Armed with that the explanation might sound a bit more understandable. I'm not familiar with the project (or Clojure), but let me try to explain! > Mycelium structures applications as directed graphs of pure data transformations. There is a graph that describes how the data flows in the system. `fn(x) -> x + 1` in a hypothetical language would be a node that takes in a value and outputs a value. The graph would then arrange that function to be called as a result of a previous node computing the parameter x for it. > Each node (cell) has explicit input/output schemas. Input and output of a node must comply to a defined schema, which I presume is checked at runtime, as Clojure is a dynamically typed language. So functions (aka nodes) have input and output types and presumably they should try to be pure. My guess is there should be nodes dedicated for side effects. > Cells are developed and tested in complete isolation, then composed into workflows that are validated at compile time. Sounds like they are pure functions. Workflows are validated at compile time, even if the nodes themselves are in Clojure. > Routing between cells is determined by dispatch predicates defined at the workflow level — handlers compute data, the graph decides where it goes. When the graph is built, you don't just need to travel all outgoing edges from a node to the next, but you can place predicates on those edges. The aforementioned nodes do not have these predicates, so I suppose suppose the predicates would be their own small pure-ish functions with the same as input data as a node would get, but their output value is only a boolean. > Mycelium uses Maestro state machines and Maestro is a Clojure library for Finite State Machines: https://github.com/yogthos/maestro https://github.com/yogthos/maestro > Malli contracts Malli looks like a parsing/data structure specification EDSL for Clojure: https://github.com/metosin/malli https://github.com/metosin/malli > to define "The Law of the Graph," providing a high-integrity environment where humans architect and AI agents implement. Well, beats me. I don't know what is "The Law of the Graph" and Internet doesn't seem to know either. I suppose it tries to say how you can from the processing graph to see that given input data to the ingress of the graph you have high confidence that you will get expected data at the final egress from the graph. I do think these kind of guardrails can be beneficial for AI agents developing code. I feel that for that application some additional level of redundancy can improve code quality, even if the guards are generated by the AI code to begin with.

yogthos 7mo ago
That's mostly correct, one small correction is that cells don't have to be pure. They just have to focus on doing a single task with some hard boundaries. And what I meant with the law of the graph was simply that the graph defines the actual business logic, and then each cell is a context free component that can be plugged into it. I guess I was just trying to be clever there. The key benefit I'm finding is that cells can be reasoned about in isolation because they know nothing about one another. You don't have implicit coupling happening the way you do in normal programs that's embedded in the call graph. My approach is to use inversion of control where the cell gets some context and resources like a db connection, does some work, and produces the result. That gets passed on to the graph layer which inspects the result, and decides what cell to call next. With this approach you can develop and tests these cells as if they were completely independent programs. The context stays bounded, and the agent doesn't need to know anything about the rest of the application when working on it. The cells also become reusable, since you arrange them like Lego pieces, and snap them together into different configurations as needed.

by _flux 7mo ago

yogthos 7mo ago

That's mostly correct, one small correction is that cells don't have to be pure. They just have to focus on doing a single task with some hard boundaries. And what I meant with the law of the graph was simply that the graph defines the actual business logic, and then each cell is a context free component that can be plugged into it. I guess I was just trying to be clever there. The key benefit I'm finding is that cells can be reasoned about in isolation because they know nothing about one another. You don't have implicit coupling happening the way you do in normal programs that's embedded in the call graph. My approach is to use inversion of control where the cell gets some context and resources like a db connection, does some work, and produces the result. That gets passed on to the graph layer which inspects the result, and decides what cell to call next. With this approach you can develop and tests these cells as if they were completely independent programs. The context stays bounded, and the agent doesn't need to know anything about the rest of the application when working on it. The cells also become reusable, since you arrange them like Lego pieces, and snap them together into different configurations as needed.