What are you doing this week?

I’m rooting for you and your spite project.

Love to hear this.

Yeah internet search is a surprisingly accessible, but also very deep and rewarding rabbit hole.

Can recommend Search Engines and Information Retrieval in Practice as a free e-book if you want some meat on your bones. Is a few years old but a lot of stuff still holds up.

I wascurrious about your cv but the site in your bio doesn't seem to load for me.

I wish you success!

I just looked at the XPath spec and realized that most of XPath is made up of a very complex expression language, and that Gleam is a perfectly cromulent expression language... so I think I'll just be implementing axis navigation and leave the expression part to a fn(Node) -> Bool. Maybe I'll implement XPath some other time.

Why was such a treasure. I mourn his disappearance tho it was by choice

Work: Hopefully finishing up some projects that have dragged on for far too long. Building new images for our VDI has become a massive problem due to internal configuration tools expecting all new machines to be physical laptops, and treating them as such, causing virtualization software to break in all sorts of ways.

Personal: Continuing to work on Writing an Interpreter in Go. I've just finished implementing the Pratt Parser. Very fun project, and the book is pretty well done.

A lot of things, actually:

• adding packages index for Tada - my opinionated Ada package manager / project builder [1]
• extending Tackle - my personal class library [2]
• adding an embedded testing framework for Tada, so the UX of creating a new project is seamless

[1] https://github.com/tomekw/tada

[2] https://github.com/tomekw/tackle

I'm working on a workflow engine with the aim of explicitly separating implementation details from the execution graph. My goal is to provide structure for building large applications out of small components that can be reasoned about independently and reused. We can break applications up by treating them as state machines. Then for any workflow you can draw out a state chart where you have nodes that do some computation, and then the state transitions to another node in the graph.

The problem with traditional coding style is that we implicitly bake this graph into function calls. You have a piece of code that does some logic, like authenticating a user, and then it decides what code should run after that. And that creates coupling, cause now you have to trace through code to figure out what the data flow actually is. This can be difficult to do because it causes context to quickly grow in unbounded way.

The key idea is to do inversion of control. Instead of having nodes in the call graph call each other, why not pull that logic out. We could pass a data structure around that each node gets as its input, it does some work, and then returns a new state. A separate orchestration component manages the workflow and inspects the state and decides which edge of the graph to take.

The graph can be visually inspected, and it becomes easy for the human to tell what the business logic is doing. The graphs are declarative in nature focusing on the state transition logic. They’re decoupled from the actual implementation details that live in the logic of each node abstracted over by its API.

Going back to the user authentication example. The handler could get a parsed HTTP request, try to look up the user in the db, check if the session token is present, etc. Then update the state to add a user or set a flag stating that user wasn’t found, or wasn’t authenticated. Then the orchestrator can look at the result, and decide to either move on to the next step, or call the error handler.

Now we basically have a bunch of tiny programs that know nothing about one another, and they have a fixed context that doesn’t grow in unbounded fashion. On top of that, we can have validation boundaries between each node, so we can check that the component produces correct output, handles whatever side effects it needs to do correctly, and so on. Testing becomes much simpler too, cause now you don’t need to load the whole app, you can just test each component to make sure it fills its contract correctly.

What’s more is that each workflow can be treated as a node in a bigger workflow, so the whole thing becomes composable. And the nodes themselves are like reusable Lego blocks, since the context is passed in to them.

This whole idea isn’t new, workflow engines have been around for a long time. The reason they don’t really catch on for general purpose programming is because it doesn’t feel natural to code in that way. There’s a lot of ceremony involved in creating these workflow definitions, writing contracts for them, and jumping between that and the implementation for the nodes. But the equation changes when we’re dealing with LLMs, they have no problem doing tedious tasks like that, and all the ceremony helps keep them on track.

https://github.com/yogthos/mycelium