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…
A curated list of falsehoods programmers believe
31–40 of 128 posts
Re: A curated list of falsehoods programmers believe
#32It's an interesting resource but perhaps the title of it is a little egoistic/presumptuous in that regard.
Re: A curated list of falsehoods programmers believe
#33This doesn't seem curated. It just seems like a list (a long one bloated one at that).
Re: A curated list of falsehoods programmers believe
#34After 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…
If you work for a very specific market, provide a canonical way to input the names, but be very very lenient to omissions or extra information. For example, in official Russian documents it's Surname-Name-Patronimic. Which will of course break for immigrants, asylum seekers, foreigners etc. But you can still provide (and store) the names in that order, but let people omit any/all of the fields (and make sure they acc…
How does it break? Wouldn't government just form patronimic from fathers name and call it a day?
Re: A curated list of falsehoods programmers believe
#35> The term "domain-specific language" has meaning.
It means "is a computer language specialized to a particular application domain".
The fact that it is hard to draw the line between DSL and general purpouse, that DSLs grow too large, ... does not invalidate the meaning of the concept.
Or:
> It is meaningful to talk about the speed of a programming language.
It is? When I have to perform a given computation within a given time on a given hardware, the same algorithm can be fast enough in one language and too slow in another. Except if you want to nitpick and see _language_ independently of _implementation_, which is a valid point, but has little practical meaning.
Re: A curated list of falsehoods programmers believe
#36Re: A curated list of falsehoods programmers believe
#37After 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…
I've dealt with that on a project for Kuwait embassy. The solution was to create a 2 fields (columns) in a separate table that was linked by ID to main "users" table and the UI would ask the user to add whatever wanted and name the field. Then when searching the algorithm would categorize the most used ones and present them from time to time to Admin that would manually add as options for general search UI. As times…
Re: A curated list of falsehoods programmers believe
#38Unfortunately - especially when dealing with non-technical ideas - some of these "falsehoods" veer into opinion territory. It's an interesting resource but perhaps the title of it is a little egoistic/presumptuous in that regard.
Re: A curated list of falsehoods programmers believe
#39Earlier quoted context omitted.
If you work for a very specific market, provide a canonical way to input the names, but be very very lenient to omissions or extra information. For example, in official Russian documents it's Surname-Name-Patronimic. Which will of course break for immigrants, asylum seekers, foreigners etc. But you can still provide (and store) the names in that order, but let people omit any/all of the fields (and make sure they acc…
>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?
- 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, -[]ich). Once you get foreign names, this becomes weird even with European names, and they are often related to a degree to Russian names. Asian names become weird to the extreme, especially with names like Hui which are a cuss word in Russian [1] John -> Johnovich may work, but Huich will not :)
- People born to/raised by two mothers will not have a patronymic. There are cases even now when people give their kids a matronymic, but that is a battle against bureaucracy.
- And this goes beyond just patronymics. There will be people who don't have a surname. Or the name/surname will include numbers which are not allowed in Russian, but are common in English (John Smith the Third etc.). But by no I'm just reiterating the falsehoods :)
Re: A curated list of falsehoods programmers believe
#40Earlier quoted context omitted.
You are right. I don't understand why developers should take into consideration any possible psychological quirk of any potential user.
No, the issue is quite simply: why does your system care what gender the person has? Unless it has a specific need for it, don't even bother You might ask if it should use Mr./Ms. (or Dr. or some other academic title) etc but even that is a bit anachronistic. Maybe this makes sense if you're sending mail to your customer, but even then. How to solve 50% of your GDPR troubles: stop asking for data you have absolutely…