4 ms·

I dislike when lists are written in such a way that the reader must mentally negate all of the statements the author is making. It's more difficult for me to qu

by tarblog 13y ago

I dislike when lists are written in such a way that the reader must mentally negate all of the statements the author is making. It's more difficult for me to quote or remember out of context correctly. I also feel like I learned a lot less than if the author had told me the things that are common problems and how to fix them or offered a model of names that is less-bad than the one most websites use.

chaz 13y ago
It's satire. 12. People’s names are case sensitive. 13. People’s names are case insensitive. Edit: Let me explain ... I was responding to the parent post, and that it wasn't meant to be a logic list of rules. Individual points may be true, but the overall tone of the list and post uses humor to explain the complexity of names. 32. People’s names are assigned at birth. 33. OK, maybe not at birth, but at least pretty close to birth. 34. Alright, alright, within a year or so of birth. 35. Five years? 36. You’re kidding me, right?
- viraptor 13y ago
  Is it? I read it as: depending on culture, the name may be either case sensitive, or not. (alternatively - someone's name may use alphabet with no concept of "case")
  - GuiA 13y ago
    I wouldn't call it satire; they are, as the title indicates, falsehoods. That is, if your code makes any of the assumptions listed, then you're handling names in a way that inevitably won't work for users of certain cultures.
- mcv 13y ago
  It's not satire. They are both bad assumptions, bound to be false somewhere. Don't let your code rely on either of these assumptions.
- hyperpape 13y ago
  Case sensitive and case insensitive sound like they're the only two options, but they're not. Take SQL as an example: are programs case-sensitive or case-insensitive? Neither!
  - specialist 13y ago
    I just got bit by inconsistent case sensitivity. My tool inspects SQL schemas. I switched from hand-rolled queries, which weren't portable, to using JDBC MetaData methods. Mostly worked. Until I did a live demo. Oops. Now have a hybrid solution.
- raverbashing 13y ago
  "It's satire" Absolutely not! Case sensitivity varies amongst countries. One very simple occidental example: in France names are usually written LASTNAME Firstname So if you type Lastname and your DB doesn't normalize the capitalization of names you won't match So for the last name the search is case insensitive but for the first name not so much. Another example is Turkish, where there are two capital I's, one with a dot, one without. And not alphabets have a notion of case.
  - abrowne 13y ago
    > Another example is Turkish, where there are two capital I's, one with a dot, one without. It's even more complicated: they have two letter Is, one with a dot in both lower and uppercase (İ/i) and one dotless (I/ı) in both cases. So any automatic case change needs to take this into account or the letter will get switched. This also make using fonts with fi ligatures problematic. http://en.wikipedia.org/wiki/Dotless_I http://en.wikipedia.org/wiki/Dotless_I
  - lstamour 13y ago
    This is also why quite a few programs have bugs when running on Turkish phones if they use locale-default case changes. Always specify a US English locale if you need to send along a certain code in uppercase, or process other inputs in ASCII. Internationalisation is tough. My favourite part is when systems don't allow last names with "special characters" including spaces, hyphens and periods.
  - rmc 13y ago
    And even normalizaing capitalization of names isn't always simple. How do you correctly capitalize "mcgee"? "Mcgee" or "McGee"?
- saraid216 13y ago
  Satire is a deliberate mockery of the subject material in order to criticize it. You don't call something satire just because one of its bullet points is kinda funny.
hyperpape 13y ago
That's the thing. I don't know if there is "a right way to do it." Maybe names are a domain that is hard enough that you can't propose the right way to handle them--you just have to know the problems that can arise, do your best for the users you expect to have, and be prepared to rework if you need to. The problem with the google+ real names policy isn't that their algorithms aren't smart enough (though it seems that they could use some work). The problem is that they're too arrogant to recognize that their algorithms are unreliable and indifferent to the ways that this unreliability is bad for users.
vidarh 13y ago
The point is you shouldn't even try. The list is not there to get you to follow every point, but to illustrate that no matter what you think you can do to validate names, you're likely wrong, so don't even try. Think about what limitations are absolutely necessary for your specific usage instead. E.g. if you want to be able to greet a user, ask them how they want to be greeted, rather than try to guess at which part of their name a user prefers to be addressed by and how to extract that part from their full name.
InclinedPlane 13y ago
The problem is that handling names semantically "correctly" is a logistical nightmare that is even more difficult than dealing with timestamps and time zones. No sane person thinks it's a good idea to just roll their own time zone implementation routinely, but people usually think rolling their own name handling system is a good idea. The purpose of patio11's advice is specifically to discourage people from doing that. And fortunately for names there are some reasonably good options, such as avoiding trying to handle names semantically at all and instead leaving them as more or less freeform user data.
patio11 13y ago
This is a very deliberate stylistic choice. Compare: "People have, at this point in time, exactly one official name." <-- phrase is false "There exist at least some people who will, at at least some instants in time, have either zero or two or more official names." <-- phrase is true Now multiply that sort of circumlocution by 40. I frequently receive the feedback "I wish you had identified a solution", which suggests to me maybe I missed the opportunity to title the post "Names are intractable hard and any programmer who thinks their program has solved them is wrong." I thought that was pretty explicit in the first paragraph but people seem to really WANT this problem to have a Ruby gem available such that they don't have to worry about it. I want dragons, but will live with my disappointment.

by tarblog 13y ago

chaz 13y ago

It's satire. 12. People’s names are case sensitive. 13. People’s names are case insensitive. Edit: Let me explain ... I was responding to the parent post, and that it wasn't meant to be a logic list of rules. Individual points may be true, but the overall tone of the list and post uses humor to explain the complexity of names. 32. People’s names are assigned at birth. 33. OK, maybe not at birth, but at least pretty close to birth. 34. Alright, alright, within a year or so of birth. 35. Five years? 36. You’re kidding me, right?

viraptor 13y ago
Is it? I read it as: depending on culture, the name may be either case sensitive, or not. (alternatively - someone's name may use alphabet with no concept of "case")
- GuiA 13y ago
  I wouldn't call it satire; they are, as the title indicates, falsehoods. That is, if your code makes any of the assumptions listed, then you're handling names in a way that inevitably won't work for users of certain cultures.
mcv 13y ago
It's not satire. They are both bad assumptions, bound to be false somewhere. Don't let your code rely on either of these assumptions.
hyperpape 13y ago
Case sensitive and case insensitive sound like they're the only two options, but they're not. Take SQL as an example: are programs case-sensitive or case-insensitive? Neither!
- specialist 13y ago
  I just got bit by inconsistent case sensitivity. My tool inspects SQL schemas. I switched from hand-rolled queries, which weren't portable, to using JDBC MetaData methods. Mostly worked. Until I did a live demo. Oops. Now have a hybrid solution.
raverbashing 13y ago
"It's satire" Absolutely not! Case sensitivity varies amongst countries. One very simple occidental example: in France names are usually written LASTNAME Firstname So if you type Lastname and your DB doesn't normalize the capitalization of names you won't match So for the last name the search is case insensitive but for the first name not so much. Another example is Turkish, where there are two capital I's, one with a dot, one without. And not alphabets have a notion of case.
- abrowne 13y ago
  > Another example is Turkish, where there are two capital I's, one with a dot, one without. It's even more complicated: they have two letter Is, one with a dot in both lower and uppercase (İ/i) and one dotless (I/ı) in both cases. So any automatic case change needs to take this into account or the letter will get switched. This also make using fonts with fi ligatures problematic. http://en.wikipedia.org/wiki/Dotless_I http://en.wikipedia.org/wiki/Dotless_I
- lstamour 13y ago
  This is also why quite a few programs have bugs when running on Turkish phones if they use locale-default case changes. Always specify a US English locale if you need to send along a certain code in uppercase, or process other inputs in ASCII. Internationalisation is tough. My favourite part is when systems don't allow last names with "special characters" including spaces, hyphens and periods.
- rmc 13y ago
  And even normalizaing capitalization of names isn't always simple. How do you correctly capitalize "mcgee"? "Mcgee" or "McGee"?
saraid216 13y ago
Satire is a deliberate mockery of the subject material in order to criticize it. You don't call something satire just because one of its bullet points is kinda funny.

hyperpape 13y ago

That's the thing. I don't know if there is "a right way to do it." Maybe names are a domain that is hard enough that you can't propose the right way to handle them--you just have to know the problems that can arise, do your best for the users you expect to have, and be prepared to rework if you need to. The problem with the google+ real names policy isn't that their algorithms aren't smart enough (though it seems that they could use some work). The problem is that they're too arrogant to recognize that their algorithms are unreliable and indifferent to the ways that this unreliability is bad for users.

vidarh 13y ago

The point is you shouldn't even try. The list is not there to get you to follow every point, but to illustrate that no matter what you think you can do to validate names, you're likely wrong, so don't even try. Think about what limitations are absolutely necessary for your specific usage instead. E.g. if you want to be able to greet a user, ask them how they want to be greeted, rather than try to guess at which part of their name a user prefers to be addressed by and how to extract that part from their full name.

InclinedPlane 13y ago

The problem is that handling names semantically "correctly" is a logistical nightmare that is even more difficult than dealing with timestamps and time zones. No sane person thinks it's a good idea to just roll their own time zone implementation routinely, but people usually think rolling their own name handling system is a good idea. The purpose of patio11's advice is specifically to discourage people from doing that. And fortunately for names there are some reasonably good options, such as avoiding trying to handle names semantically at all and instead leaving them as more or less freeform user data.

patio11 13y ago

This is a very deliberate stylistic choice. Compare: "People have, at this point in time, exactly one official name." <-- phrase is false "There exist at least some people who will, at at least some instants in time, have either zero or two or more official names." <-- phrase is true Now multiply that sort of circumlocution by 40. I frequently receive the feedback "I wish you had identified a solution", which suggests to me maybe I missed the opportunity to title the post "Names are intractable hard and any programmer who thinks their program has solved them is wrong." I thought that was pretty explicit in the first paragraph but people seem to really WANT this problem to have a Ruby gem available such that they don't have to worry about it. I want dragons, but will live with my disappointment.