This was a really nice talk. I particularly enjoyed the name and mouth feel of “obligation propagation”.
Nice talk. I’m going to have to rewatch it a few times.
I found the talk very good. Out of curiosity, I looked up her “Parse, Don’t Validate” blog post which I’m linking here for those that are interested:
I found the blog post to be a great companion to the talk, and in particular the “Use a data structure that makes illegal states unrepresentable.” idea feels like a natural single sentence distillation of her talk.
Returning
Maybeis undoubtably convenient when we’re implementinghead. However, it becomes significantly less convenient when we want to actually use it! Sinceheadalways has the potential to returnNothing, the burden falls upon its callers to handle that possibility, and sometimes that passing of the buck can be incredibly frustrating.
This is one of the takeaways from the Talk and her Blog post that I took away. Think about how the API is used not just the ease of implementing it. It aligns with top down design where you design an API at it’s call sites before implementing it.
I really resonated with this talk! I’ve felt like every single example she came up with I encountered in my current project, came to the same conclusion, implemented the same solutions.
The NonEmptyList<T> is my caty.intf.Trace, the User with fields that depends on each other is my caty.impl.core.HasField with the Value enum that used two independent fields .is_comptime and .has_default. I also had a lot of instances of her TimeRange example, like caty.impl.builtin.HasSize, but after trying her range approach I ended up changing the feature slightly and allow either a maximum xor a minimum (xor exact) instead.