5 ms·

You can’t model the entire world. Well, you can, but you can’t. Take a look at schema.org to see where that rabbit hole will take you. So instead we use more pr

You can’t model the entire world. Well, you can, but you can’t. Take a look at schema.org to see where that rabbit hole will take you. So instead we use more primitive tools that allow us to model our domain without needing a tool that magically knows how to do it for us. My domain has unique nouns that differ from someone else’s. JSON offers building blocks of primitive types like integers and strings and can be used to build more sophisticated types like “timezone aware datetime”. We use ISO8601 for this. We can use that inside JSON. Now you and I can agree on what a date is. We could build this into the language itself - but many would argue the beauty of JSON is in the fact that it is very naive and can be used quite literally to model any scenario.

cratermoon 6y ago
> We use ISO8601 Ah yes, the old "stringly typed" data model. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... Application developers aren't trying to model the entire world, they are trying to model their domain, and I'm sorry, but primitive strings, numbers, lists, and maps are the building blocks of a domain model, but they are not sufficient. See for example https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/
- earthboundkid 6y ago
  The F# post argues for marking OptionalStrings, but that’s bad design. There’s basically never a real distinction between string absent and string blank and if somehow your domain did have that distinction, you would need to record it as a bool or enum that clearly lays out “this is really blank and not just we don’t know it” or whatever.
  - cratermoon 6y ago
    > There’s basically never a real distinction between string absent and string blank Oh, child. If someone came to me claiming that something not existing was the same as that thing existing but being empty, I might be inclined to refer them to a remedial course on logic.
    - earthboundkid 6y ago
      Give a business example for a string specifically being modeled where blank is valid and distinct from null which isn’t better represented by a separate column for entry state.
      - cratermoon 6y ago
        There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy
        earthboundkid 6y ago
        I too can quote something instead of addressing the topic of discussion. “Shimmy shimmy ya shimmy ya shimmy yay.”
  - lmm 6y ago
    > There’s basically never a real distinction between string absent and string blank On the contrary, this comes up all the time; there are plenty of times when blank really is a valid value, and even if blank isn't a valid value, abusing it as a representation for "unknown" is bad for all the usual reasons in-band signalling is bad. > you would need to record it as a bool or enum that clearly lays out “this is really blank and not just we don’t know it” or whatever. An actual sum type is a million times better than using two awkwardly coupled fields. Type systems without sum types are a joke and there's no excuse for using them in the current millenium.
    - earthboundkid 6y ago
      Give examples. I have never seen a case where there was a business reason to distinguish a null vs blank string. Dates? Yes. Numbers? Yes. Strings? Nope, never. Let’s start with the most common false example: middle names. What are you going to do differently in your app if some one has an unknown vs a blank middle name? … Nothing. The displays will be the same. The search will still have to account for ignoring middle names because missing middle name might show up as “NMI” in an external system. There are no implications to having a missing middle name vs no middle name. You might need a flag for “date that the user verified that this is their full name” but that has nothing to do with null strings.
      - lmm 6y ago
        Error message "" is very different from no error message. Any legitimate use case for a null/absent string is an example; all those use cases are arguable and domain-specific, but they're a different thing from blank. For example if you're using null/absent to represent "unknown" then your search behaviour should be different from empty - for your example of middle names, a search with first=William/middle=Henry/last=Gates should return records with middle=null, but should not return records with middle="".
        earthboundkid 6y ago
        Why would you send a blank error message? Surely you would at least send “Unknown error”.
  - giantDinosaur 6y ago
    This reminds me of using DynamoDB, which didn't (until recently) accept the empty string as a value, instead helpfully offering to change it to null. However, there was a clear difference between a field in our database that a user had intentionally left blank and null as in the missing value which was usually indicative of some kind of scripting, API, or validation error. It is rather annoying that these assumptions get made.
    - cratermoon 6y ago
      Lots of programming languages treat 0 and null as the same thing. Numeric database columns, however, do not. This has resulted, at one of my employers, of a mix of different languages and systems treating 0 and equal to null. Sometimes, but not always. That inconsistency is a source of a fair number of bugs.
      - earthboundkid 6y ago
        Numbers are totally different than strings. 0 is a distinct number in a way that blank is not a distinct string.

cratermoon 6y ago

> We use ISO8601 Ah yes, the old "stringly typed" data model. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b... Application developers aren't trying to model the entire world, they are trying to model their domain, and I'm sorry, but primitive strings, numbers, lists, and maps are the building blocks of a domain model, but they are not sufficient. See for example https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/

earthboundkid 6y ago
The F# post argues for marking OptionalStrings, but that’s bad design. There’s basically never a real distinction between string absent and string blank and if somehow your domain did have that distinction, you would need to record it as a bool or enum that clearly lays out “this is really blank and not just we don’t know it” or whatever.
- cratermoon 6y ago
  > There’s basically never a real distinction between string absent and string blank Oh, child. If someone came to me claiming that something not existing was the same as that thing existing but being empty, I might be inclined to refer them to a remedial course on logic.
  - earthboundkid 6y ago
    Give a business example for a string specifically being modeled where blank is valid and distinct from null which isn’t better represented by a separate column for entry state.
    - cratermoon 6y ago
      There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy
      - earthboundkid 6y ago
        I too can quote something instead of addressing the topic of discussion. “Shimmy shimmy ya shimmy ya shimmy yay.”
- lmm 6y ago
  > There’s basically never a real distinction between string absent and string blank On the contrary, this comes up all the time; there are plenty of times when blank really is a valid value, and even if blank isn't a valid value, abusing it as a representation for "unknown" is bad for all the usual reasons in-band signalling is bad. > you would need to record it as a bool or enum that clearly lays out “this is really blank and not just we don’t know it” or whatever. An actual sum type is a million times better than using two awkwardly coupled fields. Type systems without sum types are a joke and there's no excuse for using them in the current millenium.
  - earthboundkid 6y ago
    Give examples. I have never seen a case where there was a business reason to distinguish a null vs blank string. Dates? Yes. Numbers? Yes. Strings? Nope, never. Let’s start with the most common false example: middle names. What are you going to do differently in your app if some one has an unknown vs a blank middle name? … Nothing. The displays will be the same. The search will still have to account for ignoring middle names because missing middle name might show up as “NMI” in an external system. There are no implications to having a missing middle name vs no middle name. You might need a flag for “date that the user verified that this is their full name” but that has nothing to do with null strings.
    - lmm 6y ago
      Error message "" is very different from no error message. Any legitimate use case for a null/absent string is an example; all those use cases are arguable and domain-specific, but they're a different thing from blank. For example if you're using null/absent to represent "unknown" then your search behaviour should be different from empty - for your example of middle names, a search with first=William/middle=Henry/last=Gates should return records with middle=null, but should not return records with middle="".
      - earthboundkid 6y ago
        Why would you send a blank error message? Surely you would at least send “Unknown error”.
- giantDinosaur 6y ago
  This reminds me of using DynamoDB, which didn't (until recently) accept the empty string as a value, instead helpfully offering to change it to null. However, there was a clear difference between a field in our database that a user had intentionally left blank and null as in the missing value which was usually indicative of some kind of scripting, API, or validation error. It is rather annoying that these assumptions get made.
  - cratermoon 6y ago
    Lots of programming languages treat 0 and null as the same thing. Numeric database columns, however, do not. This has resulted, at one of my employers, of a mix of different languages and systems treating 0 and equal to null. Sometimes, but not always. That inconsistency is a source of a fair number of bugs.
    - earthboundkid 6y ago
      Numbers are totally different than strings. 0 is a distinct number in a way that blank is not a distinct string.