Does Hamilton play well with code which is more structured around classes or would we need to refactor everything to be static functions? I'm wondering what the expected practise is for managing state in a purely functional design?

Hey! Hamilton doenst play super nice with classes, but there are generally good practices here that make it easy to migrate. You can think of classes as having two purposes: 1. Grouping functions 2. Carrying state For (1) Hamilton leverages modules — these can even form some sort of loose interface (e.g. so you can plug and play). For (2) you want to be careful — it’s functionally equivalent to storing the outputs and passing it in the next time. We also designed Burr for more stateful types of operations. github.com/dagworks-inc/burr Curious — what do you need state for?

We have some state that is caches of various calculations we need to re-use, e.g. The last value of an exponential moving average that we need to keep updating. We also tend to keep our config associated with the class it affects, which acts as another form of state. As you say there's nothing that couldn't be done by refactoring our classes away and storing the state separately and passing it in as arguments but rightly or wrongly we went down an object orientated route in our codebase, so I'm guessing a move to Hamilton for us has to really start with a big refactor to a functional approach?

So yeah, Hamilton is pretty oriented around functional capabilities. You could carry state through a variety of, but you generally want to either recompute for all time (if it’s smaller data) or store state extenally and pass back in. Some additional options: 1. You could call out to a Hamilton DAG within one of your classes — E.G. if you have some specific component of compute that you want to tease out functionally 2. You could pass stateful objects through your code and modify them — this is an OK way of bridging the gap 3. (bigger refactor) You could pass in the state objects, run through the functions, return it out, and merge it back into the final state outside Do you have a quick bit of sample code that illustrates it?

Just to chime in, moving to Hamilton need not be all or nothing. Hamilton is pretty lightweight and you can have Hamilton within Hamilton etc. so can incrementally move/refactor stuff. Expanding on (2) above, Hamilton functions could wrap existing objects/classes you have and just exercise the right methods on them, with the caveat of handling object mutation...

Thanks guys, much appreciate the help here 🙇 I think I have all I need for now but will let you know if I have any further questions 👍