i have encountered the "no optional fields on network messages" argument before, often from nominative type likers
but in practice, new fields are always optional: clients need to be able to downgrade requests to talk to old servers
and servers have to be able to upgrade old requests to avoid having 200 code paths
really you only have two types of network message: every field is optional
and the three or four cases where that's not true, like "vec3"
@tef fond memories of supporting a social care CRM
> this person lived in Greendale in 2017
BZZZT WRONG [OverlapException], as of 2021 they live in Camberwick Green
> can I tell you this person lived in Greendale from 2017-2021
NO FUCK OFF
> this person never lived in Camberwick Green
OK
> this person lived in Greendale as of 2017
OK
> this person moved to... fuck... Camberwell in 2021
OK
> does it matter that we don't know when they started/stopped living anywhere, just where they happened to be at two points in time
WHAT ARE YOU, A FUCKING DATA SCIENTIST
> but some of the start/end dates actually are definite and relevant dates, e.g. when someone began to be homeless
RAISE A SUPPORT TICKET SO WE AND YOUR MANAGER CAN BOTH TELL YOU TO FUCK OFF
@tef I daydream of a CRM which would serve as a notetaking app for a murder mystery novel - you're not recording platonic truths about reality, you're taking statements from a variety of variously reliable sources, aggregating them together and seeing what statements cause a conflict with the others. i.e. managing conflict rather than trying to ban it
