4 ms·

>A string value is not a great type to convey a user's email address or their country of origin. So we have a type for "country of origin". And then some count

>A string value is not a great type to convey a user's email address or their country of origin. So we have a type for "country of origin". And then some country that you have in the records splits up into 2 countries, what do you do then? Do you keep a list of all countries that ever existed and keep it up to date? This approach works good in some cases, but not always

Ygg2 4y ago
That's an unrelated problem, that's outside the scope of model presented. Remember the physicists adage: All models are wrong, some are useful. You can have your name change as well, or your calendar can change, or etc. Does that mean we stringly type everything? No. You model changes either via a separate field(s) or some kind of change table.
- musingsole 4y ago
  It's a very related problem. I agree: All models are wrong; some are useful. A string is a wrong model for an email address. But it's a pretty useful one. A custom type sitting lonely in an isolated codebase IS ALSO A WRONG MODEL. Arguably, it might be more a useful one than a string. But that's debatable. And on that debate, I'll argue a string is a better model because it is a better UNDERSTOOD model by more PEOPLE than whatever MyEmailClassForThisProject you just came up with.
  - Ygg2 4y ago
    > It's a very related problem. It's not. You have the same problem regardless of type you place there. > A string is a wrong model for an email address. But it's a pretty useful one. Depends on use case. Perhaps it's an overkill in this toy example. I've real life use cases with untrusted user input where having raw string as untrusted and some kind of verified type as trusted would eliminate whole swath of errors.
- mhaberl 4y ago
  > You can have your name change as well, or your calendar can change What do you mean by that? Having a type for "country of origin" would mean that the type gives you limits on what values it can hold (any country known to ever exist) so you can not say something like: Country c = "Foo" because Foo is not a country. I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names. The calendar example I don't get. We already have "date" types in almost all languages so that "works", although it can be used as example of how hard is to implement some types. ----- So I say: >> This approach works good in some cases, but not always And you say: > Does that mean we stringly type everything? Come on now. "Not always" does not mean "Never"
  - masklinn 4y ago
    > I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names. As always, that is very domain-specific: there are lots of countries with naming laws, some of which do have lists of legal names.
    - blep_ 4y ago
      Legitimate question: what do they do about immigration into those countries from countries without such laws?
      - masklinn 4y ago
        Likely nothing: usually they’re laws which apply to parents / birth certificates. I guess it’s possible that an immigrant trying to get naturalised would have to adopt a “legal” name for the country, but I’m not aware of any country where that’s a rule, aside from the Zairianisation movement of Mobutu.
  - Ygg2 4y ago
    > What do you mean by that? I assumed the point was old name wasn't tracked and should be. > Having a type for "country of origin" would mean that the type gives you limits on what values it can hold No one said your type has to be completely set in stone and contain every valid value in advance. Have a trusted store of country name and valid until date. So defunct country can't be added.
Smaug123 4y ago
Is the alternative to sweep it under the rug? In a stringly-typed world, what happens - do you just hope for the best? In a typed world, the problem ("the real world has ceased to conform to the model") is at least made plain so that you can decide what to do with it, because the model is actually… modelled.
- 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 ago
    I 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.
yafbum 4y ago
This problem has already been solved. Use something like https://en.m.wikipedia.org/wiki/ISO_3166-1_alpha-2 https://en.m.wikipedia.org/wiki/ISO_3166-1_alpha-2 and get an authoritative list of countries / territories, including defunct ones like Yugoslavia and USSR. You still have to define the business logic of whether you want to keep a certain country record aligned with historical borders or with current borders, but that problem exists whether you have primitive type to represent countries or not...
tremon 4y ago
What would be a use case for having a type for "country of origin" rather than a type "country"? Do you keep a list of all countries Why would you assume that once you create a type "country", it must explicitly enumerate all possible countries?

Ygg2 4y ago

That's an unrelated problem, that's outside the scope of model presented. Remember the physicists adage: All models are wrong, some are useful. You can have your name change as well, or your calendar can change, or etc. Does that mean we stringly type everything? No. You model changes either via a separate field(s) or some kind of change table.

musingsole 4y ago
It's a very related problem. I agree: All models are wrong; some are useful. A string is a wrong model for an email address. But it's a pretty useful one. A custom type sitting lonely in an isolated codebase IS ALSO A WRONG MODEL. Arguably, it might be more a useful one than a string. But that's debatable. And on that debate, I'll argue a string is a better model because it is a better UNDERSTOOD model by more PEOPLE than whatever MyEmailClassForThisProject you just came up with.
- Ygg2 4y ago
  > It's a very related problem. It's not. You have the same problem regardless of type you place there. > A string is a wrong model for an email address. But it's a pretty useful one. Depends on use case. Perhaps it's an overkill in this toy example. I've real life use cases with untrusted user input where having raw string as untrusted and some kind of verified type as trusted would eliminate whole swath of errors.
mhaberl 4y ago
> You can have your name change as well, or your calendar can change What do you mean by that? Having a type for "country of origin" would mean that the type gives you limits on what values it can hold (any country known to ever exist) so you can not say something like: Country c = "Foo" because Foo is not a country. I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names. The calendar example I don't get. We already have "date" types in almost all languages so that "works", although it can be used as example of how hard is to implement some types. ----- So I say: >> This approach works good in some cases, but not always And you say: > Does that mean we stringly type everything? Come on now. "Not always" does not mean "Never"
- masklinn 4y ago
  > I can't imagine having a type for a persons name that holds checks anything but perhaps a strings length, certainly not a list of all possible names. As always, that is very domain-specific: there are lots of countries with naming laws, some of which do have lists of legal names.
  - blep_ 4y ago
    Legitimate question: what do they do about immigration into those countries from countries without such laws?
    - masklinn 4y ago
      Likely nothing: usually they’re laws which apply to parents / birth certificates. I guess it’s possible that an immigrant trying to get naturalised would have to adopt a “legal” name for the country, but I’m not aware of any country where that’s a rule, aside from the Zairianisation movement of Mobutu.
- Ygg2 4y ago
  > What do you mean by that? I assumed the point was old name wasn't tracked and should be. > Having a type for "country of origin" would mean that the type gives you limits on what values it can hold No one said your type has to be completely set in stone and contain every valid value in advance. Have a trusted store of country name and valid until date. So defunct country can't be added.

Smaug123 4y ago

Is the alternative to sweep it under the rug? In a stringly-typed world, what happens - do you just hope for the best? In a typed world, the problem ("the real world has ceased to conform to the model") is at least made plain so that you can decide what to do with it, because the model is actually… modelled.

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 ago
  I 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.

yafbum 4y ago

This problem has already been solved. Use something like https://en.m.wikipedia.org/wiki/ISO_3166-1_alpha-2 https://en.m.wikipedia.org/wiki/ISO_3166-1_alpha-2 and get an authoritative list of countries / territories, including defunct ones like Yugoslavia and USSR. You still have to define the business logic of whether you want to keep a certain country record aligned with historical borders or with current borders, but that problem exists whether you have primitive type to represent countries or not...

tremon 4y ago

What would be a use case for having a type for "country of origin" rather than a type "country"? Do you keep a list of all countries Why would you assume that once you create a type "country", it must explicitly enumerate all possible countries?