Live data from Hacker News

A curated list of falsehoods programmers believe

github.com

61–70 of 128 posts

Re: A curated list of falsehoods programmers believe

#61
post #49

Earlier quoted context omitted.

>Store the name in two fields, have the users bend over our western form standards but be able to search and sort easily. You can't search and sort easily if the names are stored in Japanese. You need 4 fields for that. Edit: now that I think about it I could think of a disgustingly hacky way to squash them into 2 fields and retain those properties, and by extension into a single field and retain those properties.

Why would you need 4 fields?

Japanese names are written in kanji (Chinese logographic characters with semantic meaning), and pronunciation of kanji is a matter of context. Kanji in names have a variety of possible common pronunciations, meaning that when given the kanji alone the pronunciation can be ambiguous. The extra two fields are presumably for the kana (syllabary characters that are unambiguously pronounced) spelling of the names.

Even then, there are two accepted standards for sorting kana. Japanese is full of these kinds of fun exercises in writing system complexity.

Re: A curated list of falsehoods programmers believe

#62
> My system will never have to deal with names from China

I work in a small French town where Chinese people were quite rare until a few years ago. Their passports have a translation of their names in Latin alphabet, same for Russians.

However one day one of my user told me "hey I can't find some customers in your app, but I'm 100% sure I recorded them previously. Funnily they're all Chinese".

It turns out that to avoid querying the database too much I was starting to look for customers name once the user had entered at least 3 chars. Most of the Chinese names were only 2 chars like "Xi", "Wu" etc.

I clearly remember thinking at the time of writing the original code that nobody had only a 2 letter name :)

Re: A curated list of falsehoods programmers believe

#63
post #40

Earlier quoted context omitted.

I can't think of a situation where it's appropriate to ask for a title, other than for government ID. 99.9999% of the time a field for "How can we address you" with a freeform input is perfect. It lets me put in " " or "Dr. 张伟" and be done with it.

In Austria some people are VERY insistent that you use the proper title. Along with that, we need to report certain titles to the government too, because of calculating wages. And, for us, it is easier to treat all titles the same on the backend side, rather than allow freeform input.

With your case where the government requires the title being the notable exception:

> In Austria some people are VERY insistent that you use the proper title.

So let those people put their titles in the freeform input if they care.

Re: A curated list of falsehoods programmers believe

#64

> My system will never have to deal with names from China I work in a small French town where Chinese people were quite rare until a few years ago. Their passports have a translation of their names in Latin alphabet, same for Russians. However one day one of my user told me "hey I can't find some customers in your app, but I'm 100% sure I recorded them previously. Funnily they're all Chinese". It turns out that to av…

I used to know of someone who’s middle name (not just initial) was “E”. One letter.

Re: A curated list of falsehoods programmers believe

#65
post #58

Earlier quoted context omitted.

To store the furigana for the given name and family name to allow you to correctly perform sort operations.

Disclaimer: I know very little about Japanese How could you store that in a separate field from the name? Don't the characters in the furigana need to be matched up in a certain way with the characters in the name? It seems like storing the characters in line in the same field as the name would actually be the more correct thing to do here, using a system like Unicode's interlinear annotation characters for ruby text…

Where you use each field and what you use it for depends on the context.

The furigana can be used for search, sorting or display. It's most useful stored separately.

It's also not necessary to display it nicely with the ruby text as it's just a name, so dump it anywhere on the screen where someone can find it is good enough. Furigana displayed with Ruby text is useful as a reading aide in proper passages of text, usually reserved for rare words one is not expected to know and/or as a guide for children in texts aimed at younger readers.

You have to put yourself in the position of an overworked, underpaid call center worker with a CRM in front of the who has just been phoned up by a customer called Junko and they are now tasked with locating which record in the system belongs to this customer.

You see, there are something on the order of 4 or 5 different representations of this name in Kanji. If you weren't able to search by Furigana the call center staff would have to enquire which kanji it's made up of and then receive a verbal description of the radicals the kanji is composed of and in what order.

Now once they're able to find all of the "Junko"s in the system they need to narrow it down. If they were simply presented a fullname with no furigana they might well run into the prickly problem of not actually being able to read the rest of the name. At which point the conversation gets awkward again.

Re: A curated list of falsehoods programmers believe

#66
post #34

Earlier quoted context omitted.

>For example, in official Russian documents it's Surname-Name-Patronimic. Which will of course break for immigrants, asylum seekers, foreigners etc How does it break? Wouldn't government just form patronimic from fathers name and call it a day?

That's how it's usually solved, and it's a very awkward workaround: - there are cases when the father isn't known. Or even the surname isn't known (people dealing with asylum seekers run into these issues all the time) - Foreign names are not easily converted to patronymics. Russian has adapted Russian names to this scheme: Ivan —> Ivánovich, Vasily -> Vasilevich, Ilya -> Ilyich (note the suffixes -[ov]ich, -[ev]ich,…

> Once you get foreign names, this becomes weird even with European names

Wait until you think about multi-heritage names.

My son is Spanish AND Ukrainian. Ukrainian naming customs are like Russian, then in Spanish you have two last names.

This breaks down as follows: in Spanish the second last name is that of the mom, but in slavic naming customs it changes according to the gender. So in Spain he won't have the last name of the mother, and in Ukraine his last name doesn't match mine.

So he's finally name+last name+second last name for Spain, name + ugly patronymic + long ass, unique in the world last name for Ukraine.

And in both cases, the name is invariably pronounced wrong, as Spanish doesn't have the Ukrainian и sound, and Ukrainian doesn't have the Spanish z sound. Even for us the parents it doesn't come naturally to pronounce it, so it's not like we can get offended by that.

Re: A curated list of falsehoods programmers believe

#67
post #4

After reading the Falsehoods Programmers Believe About Names, I wonder, what would you recommend as a universal way to store users's names? There seems to be two main options: Store the name in a single field, be correct but lose the option to sort the names reliably. Store the name in two fields, have the users bend over our western form standards but be able to search and sort easily. Do you have any real life expe…

Store in one field. Have a secondary field `order_name` or similar, and make a best-effort attempt at extracting the proper part of the name to order on at save time (I believe there are libraries that can help with this).

Re: A curated list of falsehoods programmers believe

#68
post #4

After reading the Falsehoods Programmers Believe About Names, I wonder, what would you recommend as a universal way to store users's names? There seems to be two main options: Store the name in a single field, be correct but lose the option to sort the names reliably. Store the name in two fields, have the users bend over our western form standards but be able to search and sort easily. Do you have any real life expe…

Serious question, what is the purpose of sorting names? I presume you never give your customers a list of other customers, so such a sort couldn't be useful to them. Is it for internal reports or something? Some MBA says "get me a list of all our customers... and make sure it's sorted!" ? And is some arbitrary imperfect sorting order not adequate for this sorting need? Why not just treat the name field as a bunch of bytes and sort it with no special consideration given to the quirks of names?

Re: A curated list of falsehoods programmers believe

#69
post #43

Actually most of these things are not bound to programmers. In fact, I think programmers in general are more aware of these lists.

Yes, but in the other hand, if you don't handle validation or storage of these things it's rather irrelevant.

I wouldn’t say it’s irrelevant. If you are speaking to someone over a phone, over a counter, or through the mail, they interpret your communication through the same lens of assumptions, before it even reaches your application.

Re: A curated list of falsehoods programmers believe

#70

> My system will never have to deal with names from China I work in a small French town where Chinese people were quite rare until a few years ago. Their passports have a translation of their names in Latin alphabet, same for Russians. However one day one of my user told me "hey I can't find some customers in your app, but I'm 100% sure I recorded them previously. Funnily they're all Chinese". It turns out that to av…

I used to know of someone who’s middle name (not just initial) was “E”. One letter.

I think there's some computer scientist (or similar) whose given name is just R, I forget what their last name is though.

And apparently Johnny Cash was born J. R. Cash.

From Wikipedia:

His mother wanted to name him John and his father preferred to name him Ray, so J. R. ended up being the only compromise they could agree on. When Cash enlisted in the Air Force, he was not permitted to use initials as a first name, so he changed it to John R. Cash. In 1955, when signing with Sun Records, he started using the name Johnny Cash.

Post reply on HN