8 ms·

I like reading these lists and find them very interesting. At the same time, I would caution anyone from building software that blindly tries to accommodate ev

I like reading these lists and find them very interesting. At the same time, I would caution anyone from building software that blindly tries to accommodate every point in these lists. Every software has a set of requirements, and a target market. It should be built to meet those requirements and anticipate strange situations, but within reason. This is very context sensitive. There is no one ruleset. At the same time, it should be possible to address edge cases in some reasonable way. For example, if your software does not support pasting images in as names (and therefore cannot represent the prince symbol), it should allow transliterations into a script that it can support. We can't support all cases perfectly, but being aware o them and finding some way to fit them in makes for a better experience.

thomasfedb 8y ago
Sometimes the answer to item 29: > And will your software only be dealing with people named by your society? Is: "yep"
- Piskvorrr 8y ago
  Which is "it compiles? Ship it!" in a different cloak. And like the original, it will probably come to bite you.
  - thomasfedb 8y ago
    Often the schema is already enforced - e.g. in healthcare you'll find that somebody else has already normalized the wonderful world of names down to two Unicode strings called last and first. Names that don't fit that schema will be coerced by this wonderful technology called "an admissions clerk".
    - thfuran 8y ago
      The DICOM standard has rather more to say about names than that: A character string encoded using a 5 component convention. The character code 5CH (the BACKSLASH "\" in ISO-IR 6) shall not be present, as it is used as the delimiter between values in multiple valued data elements. The string may be padded with trailing spaces. For human use, the five components in their order of occurrence are: family name complex, given name complex, middle name, name prefix, name suffix. Any of the five components may be an empty string. The component delimiter shall be the caret "^" character (5EH). Delimiters are required for interior null components. Trailing null components and their delimiters may be omitted. Multiple entries are permitted in each component and are encoded as natural text strings, in the format preferred by the named person. For veterinary use, the first two of the five components in their order of occurrence are: responsible party family name or responsible organization name, patient name. The remaining components are not used and shall not be present. This group of five components is referred to as a Person Name component group. For the purpose of writing names in ideographic characters and in phonetic characters, up to 3 groups of components (see Annexes H, I and J) may be used. The delimiter for component groups shall be the equals character "=" (3DH). The three component groups of components in their order of occurrence are: an alphabetic representation, an ideographic representation, and a phonetic representation. Any component group may be absent, including the first component group. In this case, the person name may start with one or more "=" delimiters. Delimiters are required for interior null component groups. Trailing null component groups and their delimiters may be omitted. Precise semantics are defined for each component group. See Section 6.2.1.2. For examples and notes, see Section 6.2.1.1.
    - Piskvorrr 8y ago
      Ah! So, are you saying that it's actually not "yep, all the data fit", but "that which doesn't fit will be made to, by force if necessary"? Yup, that's what I am saying: let's just design this in a lazy way and pretend.
      - thomasfedb 8y ago
        Can you propose a schema that permits all names to be represented without requiring coercion in any case? You'll need to start with with a graphical format, or a character encoding scheme more expressive than Unicode. Computer system or not, you won't be admitted to a hospital with your name recorded as the first 1000 digits of pi followed by the emoji for coffee and a drawing of a mouse in sneakers.
        Piskvorrr 8y ago
        I can not, nor am I pretending to. What I was reacting to was this: > Sometimes the answer to item 29: > > And will your software only be dealing with people named by your society? > Is: "yep" https://news.ycombinator.com/item?id=18568710 https://news.ycombinator.com/item?id=18568710 I understand that the list is not a set of absolute rules, rather a set of caveats - even mutually exclusive ones! - and that an actual implementation will necessarily violate some of that, and that some intermediate representation would be needed. In other words, there will probably be a "name(s)" textfield, none of this graphical strawman. What I have bristled at was the abovementioned "let's wish it away, that's enough: we'll pretend that everything is ASCII and let the users cope with our design problems ad hoc."
        michaelcampbell 8y ago
        He's not wishing it away. His answer could just have been rooted in, "I understand my software won't cater to anyone. I'm ok with that." Bristle at that if you must, I guess; some people aren't happy unless they're mad.
    - nradov 8y ago
      It depends which healthcare system you're dealing with. Legacy systems often have severe limitations. The more modern HL7 CDA R2 data interchange standard has an extremely flexible model for names which can properly accommodate the majority of "falsehoods".
  - PurpleBoxDragon 8y ago
    Sometimes refusing to ship means that you just lost first to market advantage to someone who did. There are always trade offs, cost benefit analysis, and risk analysis to do with these decisions. For most software out there, assuming that a person at least has a name is a pretty safe assumption.
- JoeAltmaier 8y ago
  This is true in more places than software. Heck, even signing a check involves rendering a name in ink on paper, which is a restriction for some names I imagine. Sure its true people have different renderings for their name. So choose one that fits into the software form you're filling out. Not rocket science.
  - thomasfedb 8y ago
    My name is too long to fit on the Australian customs forms when I return from holiday. I just omit my middle names. I've yet to be refused entry.
  - biztos 8y ago
    Is there any requirement that one's signature be a handwritten version of the printed version of one's name? My signature is pretty legible at least if you already see my name in print, but I know lots of people who sign a squiggle. Your name could be ʤᔙ but you still might sign it ᠼ and I doubt anybody would care. (Made-up examples here, obviously.)
    - JoeAltmaier 8y ago
      In some cultures a signature is somewhat like a signat-ring, a written emblem not necessarily related to alphabetic sequences. An 'X' for instance, signed on a contract by an illiterate and countersigned by a witness (well that was alphabetic but you get the idea). I knew a fellow from Bangalore who's signature was a graphic, some symbol written above a line and some letters below the line.
    - bluGill 8y ago
      I'm told the squiggle is actually better than a legible signature. The legible signature is something you were trained to do following rules, and thus can be forged by someone else following the same rules. The squiggle is you, and so the existence/absence of some loop is enough to show a forgery and thus a forger has to memorize the entire thing with no rules to help. I'm not qualified to state if the above is true, but I like to believe it is.
rectangletangle 8y ago
I actually wrote a service attempting to deal with this exact problem, the amount of edge cases and exceptions make it particularly challenging, nearing that of general NLP. https://www.alphanym.com/ https://www.alphanym.com/ Probably my favorite case were some Manchurian names, which could only be spelled vertically. https://en.wikipedia.org/wiki/Nurhaci https://en.wikipedia.org/wiki/Nurhaci
- pavel_lishin 8y ago
  Wow, that actually looks like Klingon.
SilasX 8y ago
I find it interesting because it's a more universal problem that predates software. Each civilization had its own way of doing things and had to occasionally accommodate people who didn't follow its customs, and they had to use many of these very same workarounds. "You don't use our script? Okay, you'll have to come up with a version of your name that we can write in our script." "You don't have a [second] family name? We'll have to come up with a convention for deriving one when we log you." "Your name has sounds we can't pronounce? We'll treat you as having a version of your name that we can pronounce." "You don't have a signature version of your name? Uh, write X or something."
- tillinghast 8y ago
  Exactly this. Your name is not your own--your name is a contract between you and the culture / civilization you're dealing with.
- autokad 8y ago
  yeah, its like me saying my name is every character that was/is written by a human. it keeps growing. you have to accommodate me try our best, find compromises, and fail gracefully.
Bartweiss 8y ago
The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. - Douglas Adams Not only would handling every case listed be time-consuming and introduce other problems, it wouldn't be good enough. Given enough time and users, a system that needs to take and honor 'open' inputs like names will eventually hit a case it can't handle, no matter much work went into flexibility. When it does, the question that matters is whether it fails elegantly and offers some kind of usable support. Being aware of common edge cases is important to avoid getting stuck in a design that can't fail gracefully. Covering edge cases is still good, not least because cutting the amount of support you need to offer makes more time to do support well. But I hope people aren't reading these lists and concluding that the fix is to be sure they support everything on the list.
ryandrake 8y ago
I think the point of these “Falsehoods Programmers Believe” lists is not that we should all write massively complicated code to accommodate each and every edge case. The point is we should question the practice of codifying our incorrect assumptions into requirements in the form of needless restrictions and validations. Is to really necessary for your software to go through the trouble of rejecting names that contain percent signs or emoji? Why is a name over 20 characters invalid? What causes your business to stop working if your customer’s name is 21 characters? Do you really need to distinguish between a persons first and last name? What is the exact business requirement driving this? So much code out there (not to mention end user’s time) is wasted needlessly and artificially dividing user input into “good” and “bad” piles and rejecting the bad. The wisdom from these “Falsehoods” lists should result in less code, not more code.
- koliber 8y ago
  In my experience, the answer to each of those questions is "sometimes yes, sometimes no." Our software does not exist in isolation. If I don't ask you to separate your first name and your last name, and a need comes up to interact with another software (or manual) system that requires the first and last name to be separate, you shift the problem. It will either not be possible to interact with such a system or I will need to make the decision in my system, which is worse than asking you to do it). In a perfect world I would snap my finger and all legacy systems, government forms, and legal requirements would be updated to eliminate some of the more arbitrary (by today's standards) limitations, and would use UTF-8 encoding to boot. In a less perfect world I will choose my battles and sometimes force people whose names don't conform to the more prevalent norms of western society (which is where my clients mostly do business) to compromise. But I will be mindful and hope of a better future.

thomasfedb 8y ago

Sometimes the answer to item 29: > And will your software only be dealing with people named by your society? Is: "yep"

Piskvorrr 8y ago
Which is "it compiles? Ship it!" in a different cloak. And like the original, it will probably come to bite you.
- thomasfedb 8y ago
  Often the schema is already enforced - e.g. in healthcare you'll find that somebody else has already normalized the wonderful world of names down to two Unicode strings called last and first. Names that don't fit that schema will be coerced by this wonderful technology called "an admissions clerk".
  - thfuran 8y ago
    The DICOM standard has rather more to say about names than that: A character string encoded using a 5 component convention. The character code 5CH (the BACKSLASH "\" in ISO-IR 6) shall not be present, as it is used as the delimiter between values in multiple valued data elements. The string may be padded with trailing spaces. For human use, the five components in their order of occurrence are: family name complex, given name complex, middle name, name prefix, name suffix. Any of the five components may be an empty string. The component delimiter shall be the caret "^" character (5EH). Delimiters are required for interior null components. Trailing null components and their delimiters may be omitted. Multiple entries are permitted in each component and are encoded as natural text strings, in the format preferred by the named person. For veterinary use, the first two of the five components in their order of occurrence are: responsible party family name or responsible organization name, patient name. The remaining components are not used and shall not be present. This group of five components is referred to as a Person Name component group. For the purpose of writing names in ideographic characters and in phonetic characters, up to 3 groups of components (see Annexes H, I and J) may be used. The delimiter for component groups shall be the equals character "=" (3DH). The three component groups of components in their order of occurrence are: an alphabetic representation, an ideographic representation, and a phonetic representation. Any component group may be absent, including the first component group. In this case, the person name may start with one or more "=" delimiters. Delimiters are required for interior null component groups. Trailing null component groups and their delimiters may be omitted. Precise semantics are defined for each component group. See Section 6.2.1.2. For examples and notes, see Section 6.2.1.1.
  - Piskvorrr 8y ago
    Ah! So, are you saying that it's actually not "yep, all the data fit", but "that which doesn't fit will be made to, by force if necessary"? Yup, that's what I am saying: let's just design this in a lazy way and pretend.
    - thomasfedb 8y ago
      Can you propose a schema that permits all names to be represented without requiring coercion in any case? You'll need to start with with a graphical format, or a character encoding scheme more expressive than Unicode. Computer system or not, you won't be admitted to a hospital with your name recorded as the first 1000 digits of pi followed by the emoji for coffee and a drawing of a mouse in sneakers.
      - Piskvorrr 8y ago
        I can not, nor am I pretending to. What I was reacting to was this: > Sometimes the answer to item 29: > > And will your software only be dealing with people named by your society? > Is: "yep" https://news.ycombinator.com/item?id=18568710 https://news.ycombinator.com/item?id=18568710 I understand that the list is not a set of absolute rules, rather a set of caveats - even mutually exclusive ones! - and that an actual implementation will necessarily violate some of that, and that some intermediate representation would be needed. In other words, there will probably be a "name(s)" textfield, none of this graphical strawman. What I have bristled at was the abovementioned "let's wish it away, that's enough: we'll pretend that everything is ASCII and let the users cope with our design problems ad hoc."
        michaelcampbell 8y ago
        He's not wishing it away. His answer could just have been rooted in, "I understand my software won't cater to anyone. I'm ok with that." Bristle at that if you must, I guess; some people aren't happy unless they're mad.
  - nradov 8y ago
    It depends which healthcare system you're dealing with. Legacy systems often have severe limitations. The more modern HL7 CDA R2 data interchange standard has an extremely flexible model for names which can properly accommodate the majority of "falsehoods".
- PurpleBoxDragon 8y ago
  Sometimes refusing to ship means that you just lost first to market advantage to someone who did. There are always trade offs, cost benefit analysis, and risk analysis to do with these decisions. For most software out there, assuming that a person at least has a name is a pretty safe assumption.
JoeAltmaier 8y ago
This is true in more places than software. Heck, even signing a check involves rendering a name in ink on paper, which is a restriction for some names I imagine. Sure its true people have different renderings for their name. So choose one that fits into the software form you're filling out. Not rocket science.
- thomasfedb 8y ago
  My name is too long to fit on the Australian customs forms when I return from holiday. I just omit my middle names. I've yet to be refused entry.
- biztos 8y ago
  Is there any requirement that one's signature be a handwritten version of the printed version of one's name? My signature is pretty legible at least if you already see my name in print, but I know lots of people who sign a squiggle. Your name could be ʤᔙ but you still might sign it ᠼ and I doubt anybody would care. (Made-up examples here, obviously.)
  - JoeAltmaier 8y ago
    In some cultures a signature is somewhat like a signat-ring, a written emblem not necessarily related to alphabetic sequences. An 'X' for instance, signed on a contract by an illiterate and countersigned by a witness (well that was alphabetic but you get the idea). I knew a fellow from Bangalore who's signature was a graphic, some symbol written above a line and some letters below the line.
  - bluGill 8y ago
    I'm told the squiggle is actually better than a legible signature. The legible signature is something you were trained to do following rules, and thus can be forged by someone else following the same rules. The squiggle is you, and so the existence/absence of some loop is enough to show a forgery and thus a forger has to memorize the entire thing with no rules to help. I'm not qualified to state if the above is true, but I like to believe it is.

rectangletangle 8y ago

I actually wrote a service attempting to deal with this exact problem, the amount of edge cases and exceptions make it particularly challenging, nearing that of general NLP. https://www.alphanym.com/ https://www.alphanym.com/ Probably my favorite case were some Manchurian names, which could only be spelled vertically. https://en.wikipedia.org/wiki/Nurhaci https://en.wikipedia.org/wiki/Nurhaci

pavel_lishin 8y ago
Wow, that actually looks like Klingon.

SilasX 8y ago

I find it interesting because it's a more universal problem that predates software. Each civilization had its own way of doing things and had to occasionally accommodate people who didn't follow its customs, and they had to use many of these very same workarounds. "You don't use our script? Okay, you'll have to come up with a version of your name that we can write in our script." "You don't have a [second] family name? We'll have to come up with a convention for deriving one when we log you." "Your name has sounds we can't pronounce? We'll treat you as having a version of your name that we can pronounce." "You don't have a signature version of your name? Uh, write X or something."

tillinghast 8y ago
Exactly this. Your name is not your own--your name is a contract between you and the culture / civilization you're dealing with.
autokad 8y ago
yeah, its like me saying my name is every character that was/is written by a human. it keeps growing. you have to accommodate me try our best, find compromises, and fail gracefully.

Bartweiss 8y ago

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. - Douglas Adams Not only would handling every case listed be time-consuming and introduce other problems, it wouldn't be good enough. Given enough time and users, a system that needs to take and honor 'open' inputs like names will eventually hit a case it can't handle, no matter much work went into flexibility. When it does, the question that matters is whether it fails elegantly and offers some kind of usable support. Being aware of common edge cases is important to avoid getting stuck in a design that can't fail gracefully. Covering edge cases is still good, not least because cutting the amount of support you need to offer makes more time to do support well. But I hope people aren't reading these lists and concluding that the fix is to be sure they support everything on the list.

ryandrake 8y ago

I think the point of these “Falsehoods Programmers Believe” lists is not that we should all write massively complicated code to accommodate each and every edge case. The point is we should question the practice of codifying our incorrect assumptions into requirements in the form of needless restrictions and validations. Is to really necessary for your software to go through the trouble of rejecting names that contain percent signs or emoji? Why is a name over 20 characters invalid? What causes your business to stop working if your customer’s name is 21 characters? Do you really need to distinguish between a persons first and last name? What is the exact business requirement driving this? So much code out there (not to mention end user’s time) is wasted needlessly and artificially dividing user input into “good” and “bad” piles and rejecting the bad. The wisdom from these “Falsehoods” lists should result in less code, not more code.

koliber 8y ago
In my experience, the answer to each of those questions is "sometimes yes, sometimes no." Our software does not exist in isolation. If I don't ask you to separate your first name and your last name, and a need comes up to interact with another software (or manual) system that requires the first and last name to be separate, you shift the problem. It will either not be possible to interact with such a system or I will need to make the decision in my system, which is worse than asking you to do it). In a perfect world I would snap my finger and all legacy systems, government forms, and legal requirements would be updated to eliminate some of the more arbitrary (by today's standards) limitations, and would use UTF-8 encoding to boot. In a less perfect world I will choose my battles and sometimes force people whose names don't conform to the more prevalent norms of western society (which is where my clients mostly do business) to compromise. But I will be mindful and hope of a better future.