He can not be serious, can he? I thought those were just ligatures. Is he typing on an old APL keyboard?
Code is read more than written, so I have grown to appreciate programming languages that lean into non-ASCII characters for semantic clarity :)
He can not be serious, can he? I thought those were just ligatures. Is he typing on an old APL keyboard?
Code is read more than written, so I have grown to appreciate programming languages that lean into non-ASCII characters for semantic clarity :)
If the answer is “they’re all implicit in the application layer code” then that’s not really acceptable. I still need some way to query for relations, or keep relation views up to date, or something like that.
I don’t mind if relations are not core to your persistence model, but they have to be implemented _somewhere_ in your data layer, and I’m not seeing any mention of that here.
I have the same issue with Firestore, everyone does relations _somehow_ but it’s all just spaghetti application code which isn’t scalable.
Having worked with event sourced systems in the past, there are benefits in having a persisted explicit event history, but there is much added complexity (how do those read models actually get generated? how do you version the model? do you have snapshots of your read models?). In my experience, the additional complexity was not worth it for most contexts in which the pattern was applied...
Thank you for your other recommendations, I’ve just ordered both books!
Like, the F# book that Brian Kernighan would write?
[1] https://www.manning.com/books/f-sharp-in-action
[2] https://pragprog.com/titles/swdddf/domain-modeling-made-func...
Deleted Comment
Yes, it’s pretty awesome and yes, helpful. But if we extend the timeline, doesn’t this likely lead to AI-generated responses talking to AI-generated questions about AI-generated presentations?
Maybe I'm naive, but it doesn't feel like we're done building the boring stuff yet.