4 ms·
In a stringly-typed world, you still end up with a purpose-tuned model of what an email is, how it's used, and what error cases are -- these just aren't impleme
by musingsole 4y ago
In a stringly-typed world, you still end up with a purpose-tuned model of what an email is, how it's used, and what error cases are -- these just aren't implemented as qualities on a type.
There's a dozen approaches for it, many from the functional programming paradigm. But an example of one approach would be that your consumer functions become responsible for interrogating the data they'll act on -- through assertions or other verification means.
Comparing to the real world: my metal foundry doesn't yell if it gets a non-metal Type of material. But, the logical process it follows (heating to 1000+ *C) takes care of all but a handful of corner cases when you give my foundry the wrong data type.
The choice to wrap all the logic into a "Type" and then get mad when the model logic exists elsewhere is just a choice. And a weird one people get VERY OPINIONATED about.
- Smaug123 4y agoI guess I'm only opinionated about it because I'm 100% not smart enough to get it right unless something stops me getting it wrong. ("It" can be pretty much anything here.) It's why I'm such a terrible Python programmer. The foundry analogy is spot on - there's nothing to stop me throwing my grandma in, so at some point you can bet I accidentally will.
- gilbert_vanova 4y ago> I'm 100% not smart enough to get it right unless something stops me getting it wrong IMO, type systems are harsher on modeling mistakes than something like Python is. Sure, you'll get it wrong the first time (sorry Grandma!). And in Python, you can mutate your system rapidly into a new state that can accommodate the old model's mistaken assumption. If your program starts getting complex enough that the mutation speed is dropping -- deconstruct it into smaller, manageable problems. Humans are 100% not smart enough to build systems the way a lot of corporate shops keep trying to.