For EMCrit Episode 400, I do a Mind of the Resuscitationist Episode. We discuss a bunch of concepts that have been percolating through this resuscitationist's mind. #MotR
We discuss:
Wu Wei
Tension/Relaxation
BDGO
and so much more

https://emcrit.org/emcrit/motr-2025/

Welp…we just released Episode 2 of Math on the Rocks, in which we debrief our symposium experience and look ahead at our webinar series. We also dabbled in some discussion about math anxiety. #MotR #iTeachMath

https://www.cmc-math.org/podcast

Part of the reason for the disparity in https://im-in.space/@mwchase/111286554493506284 is likely that I can't figure out how to Google concepts that I only know from inventing/discovering them working on #MOTR.

Like, I'm all "well, it uses a function and this thing, to make two other things, and those things are all important for different reasons". As people have noted, Google has been less helpful as of late, and I don't even want to try to get results for "one thing that gets made into two other things".

In #MOTR, I've built so much around a piece of core functionality that I'm struggling to name, don't fully remember the design, and have trouble articulating the purpose of beyond "It makes everything else work."

In fiction this would 100% be the summoning ritual for some kind of eldritch abomination...

(Albeit, part of the struggle is that the obviously best name, "matrix", rubs me the wrong way because the conceptual space involved is not necessarily two-dimensional, but I'm worried if I call it a "tensor", people will be like "why didn't you call it a matrix?")

Some thoughts on testing the high-level interfaces to #MOTR...

I think the best way for me to assert things about the behavior right now is to make statements about reachability of actions from named targets.

Maybe I should be researching, like, what kinds of interesting properties a directed acyclic graph can have.

Hm. Looks like, in addition to comparing to tox, Nox, doit, invoke, make, and Bazel, I'll also have to see about comparing MOTR to Airflow.

Preparing to get back onto things with #MOTR. As I was working on fixing up my interfaces, I realized that one thing that would really simplify (some aspects of) the code would be to add a few more type parameters to one module, and an additional wrapper class, along with a protocol.

Stand by to learn how this all messily blows up in my face.

So, I tried to implement the code needed to make the tests pass in #MOTR, and, um...

I *think* there's some stuff in there that can get factored out? But right now I'm staring at it and hearing bass-boosted Somebody That I Used to Know.

The bug I mentioned from #MOTR last time is, I keep on forgetting that inheriting from a protocol does not automatically make the subclass a protocol. You have to inherit from Protocol explicitly.

Anyway, I could try various ways to continue on with what I did last time, but I think I'll just rip out the old protocol and throw myself on the mercy of the typechecker.

Okay, here we go.
Delete Installer, TInstaller, and replace the Registry definition with "Registry = _typed_map.TypedMap[UnlabelInstallerArgs]".

This is going to get all kinds of messy before it even leaves the file, but such is the price of progress.