@tef i was just reading this post and nodding in agreement as well

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 "The other solution some engineers seem to like - refusing to do the task, on the grounds that it’d compromise the software design - is a non-starter, in my opinion. As engineers, it’s our job to support the needs of the business."

nodding SO SO SOOOO MUCH

@tef

However, user-facing software will eventaully be forced to break many of its constraints in the interest of better fulfilling the real-world goal of that software. Thus, some invalid states ought to be representable.

Working with games almost exclusively. This is a real mood. Some places I have hard constraints such as making sure my math doesn't go sideways. But, also hard constraints for games can turn into catastrophic rewrites that spiral into more and more rewrites until a) rewrite the whole game b) give up and start on a different project.

I've been majorly burned in the past by specifying hard constraints in the wrong places 🥴

@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 think you gotta take "make invalid states unrepresentable" along with "parse don't validate". malformed, transitional, incomplete, future/past variations, etc. are "valid states" from the point of view of interfacing with the world outside, but i think you can use type system methodology still to manage how you process those states into something more sanitized for your core business logic

@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

@jackeric @tef previously joked about a *cough* sales oriented customer who was a CRM fan that actually what they needed was a Lies Management System to keep track of the conflicting truth each of their own customers was presented with

@jackeric @tef not quite that, but one day I’m going to snap and build some project management software which requires a confidence level to be provided along with all estimates, then returns schedules as a date range.

@jackeric sounds like you want to learn prolog

@jon @jackeric congrats you have invented a tool that encourages managers to punish the most honest employees heh

@tef @jackeric god damn it, tef. Can I not have one nice thing?