The only circumstance I can think of when it is simultaneously true that gender must be recorded and that edge cases (like XXY chromosomes) are not important, is that languages have gendered words — but even in German you can have linguistic constructs to get around that: https://youtu.be/mHYD5cex54A
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 no use for (and no, selling customer data is not a legitimate use)
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.
There are cultures in which the honorific is required. There are cultures in which it is not only not required but despised. I have encountered too many web forms in which a gendered honorific is required input, and you must select from a drop-down list.
The people who design those forms are second in line to be put against the wall when the revolution comes. Right behind the people who design free-form input for international telephone numbers but have a hidden undocumented mandatory format that gets rejected and all you see is a red asterisk beside the field when you "Submit" is rejected and all the other fields get blanked out.
> I have encountered too many web forms in which a gendered honorific is required input, and you must select from a drop-down list.
We have 3 gender options, mandated by law, in a dropdown which makes sense for our company. But we don't mandate honoriffics, nor do we use a gendered form where possible. And all input goes through an employee. (We are a worker leasing company, ONLY active in Austria)
> Right behind the people who design free-form input for international telephone numbers but have a hidden undocumented mandatory format that gets rejected and all you see is a red asterisk beside the field when you "Submit" is rejected and all the other fields get blanked out.
What is the obstensible purpose of this law that requires you to collect and store information about peoples' gender? I can't fathom why a legislature would ever think that necessary. It just doesn't seem like useful information in most contexts, almost like asking for astrological signs and blood type. I've seen those on forms before and they seem to serve no real purpose.
A fair few of the these lists (which are fascinating, by the way - just pick one at random) are ultimately about respecting people and culture. Being bothered to correctly handle calendars or naming conventions (and lots of other things) that may be unfamiliar is helping to include people who might otherwise be excluded, or treated as second class.
I think this can be compared to the standard trade off of doing things the right way or the quick way, which is not necessarily wrong but can blow up spectacularly. Unfortunately, sometimes the work to do things the right way is an infinite pit of edge cases and domain knowledge.
You can use libraries to paper over this trade off but then you have other trade offs like needing to worry about bugs you have no control over.
In the end, if you don’t feel at least a little bad about the software you’ve written or how long it took to write it, you are probably doing something wrong
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 accept ridiculously long names as well).
Outside of government/finanical forms there's rarely a need to worry about 100% correct sorting of names. So go just for one text field, and let people fill it out however they want.
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, -[]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 :)
>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 :)
In this case registry official simply starts writing random shit into the system and it becomes your problem. At least that's how it was with "not so Russian names" in USSR times -- just write whatever Russian name that starts with same letter.
> 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.
>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.
Oh, dealing with authorities should be fun. Last time I had been there reissuing passport for my son, ДМС officials suddenly realized, that his patronymic is somehow present in a demographic registry without being present in any primary records (birth cert, translations, applications etc). Then they spent solid 30 minutes trying to find nonexistent number of said birth certificate.
Yeah, on top he was born in France, and the consular services of either country basically say, "he'll have the name French authorities let you write"; plus patronymic, if wanted, in case of Ukraine.
Luckily we had a public servant that was familiar with naming conventions of both countries and his name is the one his mom and I agreed respected both naming conventions the most.
There are also cases of transliterating names. Belarus insists on their internal schemes, so Евгений becomes Yauheni (to match Belorussian version of the name, Яўген) when it should become at least Eugene.
The old trick of having your name mentioned in any public document issued in other country in whatever spelling you want doesn't apply in Belarus? Had to do that, because my name looks more like a barcode when transliterated from original Ukrainian spelling.
AFAIK Belarus is very rule-oriented when it comes to transliterating names. I heard it's become better in the last few years, but there are definitely plenty of Yauhenis :D
It also often boils down to the specific clerk in charge.
I personally am a Russian-speaker from Moldova, and I had four more classmates with the name Дмитрий. When we were getting our first passports, I said that I want "Dmitrii" as the name/transliteration. The woman at the counter just asked "Are you sure?", shrugged and accepted my application. All my friends suggested their own spellings at their respective passport offices, all got rejected because "the proper spelling of the name in Moldova is Dumitru" (which is the Romanian version of the name).
I think instead of trying to break names apart from one input, the best strategy is to consider the various uses you need and provide that many inputs (in a previous job writing software for art galleries, this was our solution).
So for example, you might have a "display name" field, which is the formal name-of-record that you need for any official or semi-official context (title card of an artwork, or invoice info, going on the art example).
For indexing/sorting, you can have that as a separate "index" or "sort value" field (especially where sorting is something you want to control on a per-entry basis, like the library example in one of the articles sorting names using the indexing rule of the author's place of origin, or you want to sort a list of names that contain a mix of character sets).
For addressing people directly, e.g. via email or letter, you can provide them with an extra "how should we address you" field -- the best part about this is it means you don't have to guess how they want to be addressed, and is I think the most polite option, especially when you're dealing with a variety of cultural contexts in the same system.
Typically you need several independent name fields because people may use different versions of their name, or entirely different names, in different contexts.
> what would you recommend as a universal way to store users's names?
It's unsolvable problem. Names are locale and context dependent and there is no way to translate any given name from it's canonical form (which is nonexistent) to any context you would need (except identity function obv).
So you store in-context representation(s) of name and don't transform ever. In practice that means you have one or two fields with no validation whatsoever and let user decide what to enter (while indicating what context it is!), or you apply whatever arbitrary limitation already present in system(s) you interface with. Which usually boils down do "bend over our western form standards".
Four Five Nine Alpha Six Five Bravo Foxtrot -Bravo Alpha Alpha Eight -Four Delta Five Eight -Nine Nine Five Five -Two Six Delta Echo Seven Five Charlie Five Four Zero Five Seven
Four Fife Niner Alfa Six Fife Bravo Foxtrot Bravo Alfa Alfa Eight Four Delta Fife Niner Niner Fife Fife Two Six Delta Echo Seven Fife Charlie Fife Four Fife Seven
>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.
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.
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.
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 passed on and more data was entered this way became better and better allowing for a more fine tuning of searchable data.
I shit you not, there were fields added there that our Western thinking would never dream they are needed, for example plenty of old people from Papua New Guinea added "Grandfather initial" to their name. Or others added "tribe name" as a meaning to somehow show that they are part of an extended family.
Not my style. You could read my past comments here on HN and see for yourself my different stories on different subjects, both good or bad (I can't please everyone, not that I try anyway).
I too would love to read more about this. It sounds like a great general purpose solution.
Are there any mandatory parts? Assuming not, how does sorting work? Was it a matter of sort orders being pre-programmed for more common fields (e.g. sort by last name first, then by first name) and an assumption that any name that didn't include any of the pre-programmed parts was just stuck at the end? Was it even an issue? (i.e. how many people even had a name consisting entirely of "uncommon" fields?)
Edit: Another question. You said just two fields in the secondary table (perhaps you where simplifying though...). How does display work? Presumably the user expects their grandfather's middle initial to be printed in a particular location relative to all of the other parts of their name.
The only mandatory part, from UI point of view, was the username in "users" table. On 2nd table (think was "userExt" called) everything was user generated and not required. From law point of view the data you entered in there was your responsibility to comply with both embassy requirements and your country issued ID's (personal identity card, passport, driver license, marriage license, etc).
The document was also user generated from their defined fields and was user customizable. My implementation was to allow users move fields on the form however they liked and also had an option to be saved as template to be used further by same user or others.
Sorting and filtering was the biggest issue. Since we talk about Kuweit, Unicode complaint was paramount, including Mongolian alphabet (not to mention classic pitfalls of Chinese, Japanese, Arabic). Initially I went with UTF-16. That was a big mistake and I've refactored that part of the code a year later to be UTF-8. Since this was also manually picked by Admin, it had a points system. For example if more then 10 different users would add a new field (let's say "tribe name") then Admin would get a notification about it and could be added as option, for future users, to pick when entering their data. Once defined in Admin part, it could be used for sorting/filtering like any other already defined field. As for exact sorting, I've simply let Unicode standard and the library used at the time to figure it out, I haven't done any special code on it. Best to let others smarter then you on that issue to do it, you just use their defined interfaces.
Display for Admin would show all the user defined fields, one after another. Admin also had the possibility to view them in the user saved templates. In case of using a template from another user to current user, the form would simply show a red outline and empty space there if data was missing, and if the same user had other fields not used by current view they would be enumerated at the end of current form. Forms could be on as many pages as the user wanted. Remember, this was used by embassy and everything entered online would also be manually compared with the hard copy of them by the officer in charge of your application. I don't think pranking the embassy officer with a shitty form would be nice for you since he would simply reject your application and you had to pay (the least amount was on thousand of dollars) to begin the process. Only a bored billionaire would do something like that, usual folks took great care to actually be 100% accurate.
Fun fact, this comment is the first result and only result containing all terms when Googling "UPU S1 standard". The closest relevant looking result I was able to find was the "UPU S10 standard", which doesn't seem relevant.
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).
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?
A teacher that needs a list of all the students scheduled to be in their 5:00 class.
There's literally millions of similar examples. Software where none of the users know about the other users would be fairly rare in my world (I've worked on internal business tools most of my career).
Is any arbitrary imperfect sort not adaquate for roll call? If the full names are sorted naively like any other string, why would that be a problem for teachers? I don't get this. Usually what happens is last names are placed first for sorted lists, but this seems like an arbitrary meaningless convention without real utility. And since this arbitrary convention is problematic in cases where names can take on many forms, it makes sense to disregard the convention. If you're not already accustomed to the convention it doesn't even make rational sense; why should the first name be last and the last name first? That's totally backwards, but it's convention. Why though? It's not even like that ordering will necessarily put siblings next to each other on the sorted list. Many siblings have different last names and many people who aren't siblings have the same last name, so what is the actual purpose of supporting this convention?
My name is such a convention-defying name by the way, the way I use it. Often I have to enter "[first initial] [middle name]" as my ''first name'' even though it isn't. Just give me a single name field please.
Edit: Annoying example from a minute ago: I gave my first initial/middle name to newegg. Newegg tried to be clever by dropping my middle name and now calls me simply "J." That's not my name!
You do realize that it's still illegal to do all these things with Bitcoin, right? It's not that banks can't do these things; they just have no interest performing illegal activities on your behalf. Bitcoin solves nothing here.
It's also illegal to smoke weed, drop acid, watch netflix or be gay or publish suicidal jokes in some places. Everybody draws a line for themselves in regard to which laws they have to respect or have no choice but to break today.
I am always appalled when systems (built in the US) have difficulties with apostrophes in the names. I mean, have you missed all the Irish names that exist in the US?
It would be "fair enough" forgetting about accents when computing resources were limited, but to not deal with apostrophes? Really?
It would be easier to just make all computing systems use Internet English, if a word ends in "s" and doesn't have an apostrophe before it then add one.
They probably use some terrible SQL backend and filter them out to prevent problems. Yes, that's a 2005 problem, but things take a long time to go away.
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.
Human assumptions are one thing, but if you're directly speaking to a person, you can explain your unusual name situation. There is no discussing with the input validation on a web form, though. That's why I think it's far more important for programmers rather than, for example, counter staff.
> if you're directly speaking to a person, you can explain your unusual name situation.
Sort of. I'm more thinking about situations where the person makes interpretive assumptions on their own without opportunity for discussion. You don't normally see what people are actually filling out in the application when you're talking to a customer service representative. Nor would 90%+ of western CS reps have any clue what you're even talking about if you brought up even a very common exception.
And even if your developer was smart and made those fields "given name" and "surname", your CS rep might still jam the values in the wrong fields because they're a kid in Nebraska making $12/hr who barely understands the difference between Korea and China.
It is not equivalent, but if someone has the time to read the list, I would recommend instead the reading of R. L. Glass "Facts and Fallacies of Software Engineering" [1].
Lists of falsehoods can be very useful and enlightening (especially about common things like dates, names and email addresses), but with the "falsehoods programmers believe about falsehoods" it becomes just an exercise in pedantry.
Most github list projects seem to suffer from this. For instance the infamous "awesome list" [0]. Select a category. Most of them contain several hundred items. As if this is anything better than searching google for the term.
It’s just a form of tech-blog click bait. Make some incredibly contrived claim, that makes a bold-sounding headline, but barely ends up meaning anything after you’re done with the rambling explanation. Perhaps some will end up adoring your thought-leadership, but the rest will end up talking about in on HN.
You just inspired an idea from me regarding HN comments. I think Slashdot still has one of the most elegant commenting systems around, even if the quality of the comments (due to the site's ownership) is worse.
I would love to tag HN comments with certain attributes and be able to filter them out. For example, this comment and the parent could be tagged "meta-discussion". Then those who want to discuss the content of the article could filter them out quickly.
/. tags are pretty accurate - "funny" "informative" "insightful" "trolling" - though trolling is a delete-level offense here.
Likewise, metamoderation (peer review, or moderation of tagging) was a brilliant idea.
I have been thinking about this for a while with Reddit. If users could mark why they think something is worth upvoting then everyone else could just filter to find the insightful or informative comments and get rid of the funny ones, or vice verses depending on what they were looking for at the time. Distilling down the comments to stuff you are much more likely to be interested in could improve the site quite a bit, it works on Steam fairly well for games even with a somewhat free tag system but I can't help but think that perhaps not many people would bother.
The simplification to up and down hurts discussion on Reddit (and probably on hacker news too) because it promotes widely comprehended and accepted content. This is why on Reddit pictures do so well unless they are banned, they are very quick to review and choose to up or down vote. However a 10k document will be reviewed by a lot less people, it could fit exceptionally well with the content and get 100% upvotes but be completely buried by all the pictures because a lot less people had time to view it and upvote it.
There is a deeper challenge here with how comments and upvoting and content filtering via users is done. It isn't just the lack of information from tags but also once a document is reviewed will an upvote occur. Much of Reddit shows users will widely upvote on the basis of the title of say news without ever reading it. The longer the article is the less people will return to Reddit to upvote it. Both HN and Reddit promote popularity over fit because low numbers of upvotes on content equates to low engagement and that isn't valuable to them, but it might be the singularly most important piece of content for that audience its just long and badly titled.
There are a bunch of unsolved issues that Reddit and HN have surfaced around the model for content and comment voting and where these two sites differ is mostly only in the rules to try and mitigate the problem with the chosen model. The problem is only more complicated models can improve it and the moment you do that you potentially lose customers, but at the same time you potentially don't want those customers either.
>The problem is only more complicated models can improve it and the moment you do that you potentially lose customers, but at the same time you potentially don't want those customers either.
Therein lies the key paradox. Statistically, content quality usually has the shape of the the lognormal distribution, with community size on the horizontal axis and quality on the vertical. Content below a certain margin of popularity is usually unpopular for a reason--the ideas of the community are not very good! When content quality is high, the popularity of a community rises because the ideas are good! After a critical threshold though quality goes down. Once you've reached that threshold, number of users is inversely proportional to quality. I really like HN vetting process for voting: you have to have spent enough time on the site, and commented in a way that gained sufficient approval from the existing community in order to get the right to vote in that community. Keeping barriers to entry high is critical to this, but marketing people can only see $/user.
Reddit has become increasingly intolerable for me except for a few niche subreddits.
This is probably solvable with Hypothesis and a custom browser extension.
More generally, third-party annotation of web (especially hypertext) resources is an underexplored opportunity. I suspect it’s at least partly because integration isn’t a first-class concern for these sorts of apps (if it were, they’d build it themselves and own the feature and the data), so the experience isn’t that great and the marketing is significantly diluted.
> 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.
Well, Haskell (say) can never be as fast as C++, because of immutability. That means that it has to make a new place to store the new value, which means an allocation. That's not dependent on implementation.
(Except, I suppose, you theoretically could implement C++ so that it also allocated every variable. Still, I think the point is valid: Haskell, by its nature, has to do things that C++ doesn't, so Haskell is going to have a very hard time being as fast as C++.)
Immutability doesn't mean no one can implement a Haskell extension that allows safely describing and composing operations that use mutability on the inside.
Of course on current hardware with current compiler Haskell programs tend to be slower, and also tend to be more correct compared to C/C++ (maybe even compared to let's say C++20).
Isn't it strange that bits of essential knowledge ends up being either opaque (some form of code that does some magic) or negative, as in these 'falsehoods'?
> 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 :)
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.
Interesting story, but, unfortunately, it's not true. Wiki gives his full name as "Julius Robert Oppenheimer." Julius was apparently his father's name as well.
Interesting, now that you mention it I can't think of any French names that are 2 letters long. But in English we have tons, "Ed Mo" is a perfectly plausible name.
I clicked on some of them, and most have fewer than 20 recorded instances in over 100 years. I guess it happens sometimes, but it's really not comparable to the prevalence of names like Ed, Jo, Bo etc (which aren't always contractions). The most common two letter name in France is probably something like Li or Ng.
Edit: Funny observation - when you use the system that's linked to try and look up the public records, it won't even let you search for names with less than two letters.
One of my first programming tasks as an intern was figuring out why the search function for a directory couldn't find certain users. It was the same reason you have, it just didn't return results until it had 3 or more characters!
A former UN Secretary General U Thant was actually named just Thant, with "U" being a honorific (King od like "Mr"). And the first Burmese prime minister was actually named Nu (formally U Nu). https://en.wikipedia.org/wiki/U_Nu
>Heterogenous units are of no practical use. (Radar beam height formula uses a constant expressed in nautical miles per foot)
Constants in formulas can be expressed in any unit system you want. What the author means to say is that one formula they saw in one textbook used nautical miles per foot. The "radar beam height formula" is not specific to any particular unit system.
This is kinda depressing reading for the start of the workweek.
Also, I wish each of these was more expanded.. I can think of many workarounds for each of these situations but I am curious what other people's solutions might be:
http://www.creativedeletion.com/2015/01/28/falsehoods-progra...
I read through the entire list of falsehoods about addresses and I think I've got a few more broken assumtpions that weren't listed:
* A property will have an address
(I live in a very rural area of CA where the roads have forked several times for many miles to get to a property and they are all unnamed private roads. People often just put down the APN and the nearest town (which might be several miles away) as their address. I deal with this one all the time. I routinely have to find their house for the first time. Good luck using GPS here, if you can't read a map, you're S.O.L. [And no, even trying to confirm that you are where you think you are with GPS on your phone is gonna be a challenge. For one, you're miles from cell reception so if you didn't save the map to your phone, you're screwed. For two, under heavy tree and cloud cover, you may not even get a GPS fix on a phone.])
* A recipient needs a name and address
My mother lived for a time in a very rural area nearby. She rode a BMW motorcycle and someone she met only briefly once successfully sent her a letter by simply drawing a BMW symbol as the name and address and affixing the nearest town.
* A person has a street address
Homeless and rural people regularly fail this one.
127 comments
[ 2.7 ms ] story [ 194 ms ] threadYou 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 no use for (and no, selling customer data is not a legitimate use)
And, for us, it is easier to treat all titles the same on the backend side, rather than allow freeform input.
The people who design those forms are second in line to be put against the wall when the revolution comes. Right behind the people who design free-form input for international telephone numbers but have a hidden undocumented mandatory format that gets rejected and all you see is a red asterisk beside the field when you "Submit" is rejected and all the other fields get blanked out.
We have 3 gender options, mandated by law, in a dropdown which makes sense for our company. But we don't mandate honoriffics, nor do we use a gendered form where possible. And all input goes through an employee. (We are a worker leasing company, ONLY active in Austria)
> Right behind the people who design free-form input for international telephone numbers but have a hidden undocumented mandatory format that gets rejected and all you see is a red asterisk beside the field when you "Submit" is rejected and all the other fields get blanked out.
You need a revolution to justify it?
Also: We employ people to work at a different company through us.
> 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.
You can use libraries to paper over this trade off but then you have other trade offs like needing to worry about bugs you have no control over.
In the end, if you don’t feel at least a little bad about the software you’ve written or how long it took to write it, you are probably doing something wrong
Cannot tooling and methodology make up for poor documentation or "code quality"?
Unless, of course, you are writing software that is life or death situation.. which I suspect most of us do not.
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 experience with these or other "falsehoods"?
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 accept ridiculously long names as well).
Outside of government/finanical forms there's rarely a need to worry about 100% correct sorting of names. So go just for one text field, and let people fill it out however they want.
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 :)
[1] https://en.wiktionary.org/wiki/хуй
In this case registry official simply starts writing random shit into the system and it becomes your problem. At least that's how it was with "not so Russian names" in USSR times -- just write whatever Russian name that starts with same letter.
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.
Oh, dealing with authorities should be fun. Last time I had been there reissuing passport for my son, ДМС officials suddenly realized, that his patronymic is somehow present in a demographic registry without being present in any primary records (birth cert, translations, applications etc). Then they spent solid 30 minutes trying to find nonexistent number of said birth certificate.
Luckily we had a public servant that was familiar with naming conventions of both countries and his name is the one his mom and I agreed respected both naming conventions the most.
It also often boils down to the specific clerk in charge.
I personally am a Russian-speaker from Moldova, and I had four more classmates with the name Дмитрий. When we were getting our first passports, I said that I want "Dmitrii" as the name/transliteration. The woman at the counter just asked "Are you sure?", shrugged and accepted my application. All my friends suggested their own spellings at their respective passport offices, all got rejected because "the proper spelling of the name in Moldova is Dumitru" (which is the Romanian version of the name).
So for example, you might have a "display name" field, which is the formal name-of-record that you need for any official or semi-official context (title card of an artwork, or invoice info, going on the art example).
For indexing/sorting, you can have that as a separate "index" or "sort value" field (especially where sorting is something you want to control on a per-entry basis, like the library example in one of the articles sorting names using the indexing rule of the author's place of origin, or you want to sort a list of names that contain a mix of character sets).
For addressing people directly, e.g. via email or letter, you can provide them with an extra "how should we address you" field -- the best part about this is it means you don't have to guess how they want to be addressed, and is I think the most polite option, especially when you're dealing with a variety of cultural contexts in the same system.
https://www.w3.org/International/questions/qa-personal-names
It's unsolvable problem. Names are locale and context dependent and there is no way to translate any given name from it's canonical form (which is nonexistent) to any context you would need (except identity function obv).
So you store in-context representation(s) of name and don't transform ever. In practice that means you have one or two fields with no validation whatsoever and let user decide what to enter (while indicating what context it is!), or you apply whatever arbitrary limitation already present in system(s) you interface with. Which usually boils down do "bend over our western form standards".
Four Five Nine Alpha Six Five Bravo Foxtrot -Bravo Alpha Alpha Eight -Four Delta Five Eight -Nine Nine Five Five -Two Six Delta Echo Seven Five Charlie Five Four Zero Five Seven
Four Fife Niner Alfa Six Fife Bravo Foxtrot Bravo Alfa Alfa Eight Four Delta Fife Niner Niner Fife Fife Two Six Delta Echo Seven Fife Charlie Fife Four Fife Seven
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.
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.
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.
> (furigana) <- aka pronunciations
> _konbinaetar_ | ____wai____
> .
> . Family name | Given name
> _Combinator_ | ____Wye____
And there are always irregular pronunciations so they can’t be always inferred or correlated
Even then, there are two accepted standards for sorting kana. Japanese is full of these kinds of fun exercises in writing system complexity.
I shit you not, there were fields added there that our Western thinking would never dream they are needed, for example plenty of old people from Papua New Guinea added "Grandfather initial" to their name. Or others added "tribe name" as a meaning to somehow show that they are part of an extended family.
Are there any mandatory parts? Assuming not, how does sorting work? Was it a matter of sort orders being pre-programmed for more common fields (e.g. sort by last name first, then by first name) and an assumption that any name that didn't include any of the pre-programmed parts was just stuck at the end? Was it even an issue? (i.e. how many people even had a name consisting entirely of "uncommon" fields?)
Edit: Another question. You said just two fields in the secondary table (perhaps you where simplifying though...). How does display work? Presumably the user expects their grandfather's middle initial to be printed in a particular location relative to all of the other parts of their name.
The document was also user generated from their defined fields and was user customizable. My implementation was to allow users move fields on the form however they liked and also had an option to be saved as template to be used further by same user or others.
Sorting and filtering was the biggest issue. Since we talk about Kuweit, Unicode complaint was paramount, including Mongolian alphabet (not to mention classic pitfalls of Chinese, Japanese, Arabic). Initially I went with UTF-16. That was a big mistake and I've refactored that part of the code a year later to be UTF-8. Since this was also manually picked by Admin, it had a points system. For example if more then 10 different users would add a new field (let's say "tribe name") then Admin would get a notification about it and could be added as option, for future users, to pick when entering their data. Once defined in Admin part, it could be used for sorting/filtering like any other already defined field. As for exact sorting, I've simply let Unicode standard and the library used at the time to figure it out, I haven't done any special code on it. Best to let others smarter then you on that issue to do it, you just use their defined interfaces.
Display for Admin would show all the user defined fields, one after another. Admin also had the possibility to view them in the user saved templates. In case of using a template from another user to current user, the form would simply show a red outline and empty space there if data was missing, and if the same user had other fields not used by current view they would be enumerated at the end of current form. Forms could be on as many pages as the user wanted. Remember, this was used by embassy and everything entered online would also be manually compared with the hard copy of them by the officer in charge of your application. I don't think pranking the embassy officer with a shitty form would be nice for you since he would simply reject your application and you had to pay (the least amount was on thousand of dollars) to begin the process. Only a bored billionaire would do something like that, usual folks took great care to actually be 100% accurate.
A teacher that needs a list of all the students scheduled to be in their 5:00 class.
There's literally millions of similar examples. Software where none of the users know about the other users would be fairly rare in my world (I've worked on internal business tools most of my career).
My name is such a convention-defying name by the way, the way I use it. Often I have to enter "[first initial] [middle name]" as my ''first name'' even though it isn't. Just give me a single name field please.
Edit: Annoying example from a minute ago: I gave my first initial/middle name to newegg. Newegg tried to be clever by dropping my middle name and now calls me simply "J." That's not my name!
"Okay, you don't need bitcoin if you are not sending your money to imaginary places like Iran and N'Korea"
"Okay, you don't need bitcoin in Europe or US unless one party in your transaction has surname that starts with Ass and ends with ange"
"What do you mean by saying that banks abroad could refuse to open you account if you are US citizen"
"Capital controls and war? What you are, a character in a Neal Stephenson novel or Python developer?"
It would be "fair enough" forgetting about accents when computing resources were limited, but to not deal with apostrophes? Really?
(I mean, ok, this story is not new, just look at the history of the https://www.reddit.com/r/AskHistorians/comments/1fu633/when_... )
Also, should we treat ' and ’ as equivalent?
Sabre is from the 60s and doesn't like apostrophes in names https://en.wikipedia.org/wiki/Sabre_(computer_system)
So I am glad I did not sweat over those, and got something up and running, and did not get bogged by some of those very difficult questions.
Hopefully for the projects that stick around I'll be able to do some clean-up...
Human assumptions are one thing, but if you're directly speaking to a person, you can explain your unusual name situation. There is no discussing with the input validation on a web form, though. That's why I think it's far more important for programmers rather than, for example, counter staff.
Sort of. I'm more thinking about situations where the person makes interpretive assumptions on their own without opportunity for discussion. You don't normally see what people are actually filling out in the application when you're talking to a customer service representative. Nor would 90%+ of western CS reps have any clue what you're even talking about if you brought up even a very common exception.
Example:
Form: [first name] and [last name]
CS Rep: what's your name?
Customer: "Kim Jong Un"
Resulting record: {firstname: 'Kim', lastname:'Un'}
And even if your developer was smart and made those fields "given name" and "surname", your CS rep might still jam the values in the wrong fields because they're a kid in Nebraska making $12/hr who barely understands the difference between Korea and China.
[1] https://www.amazon.com/Facts-Fallacies-Software-Engineering-...
I mean, now that I know I’m wrong, how do I become right?
[0]: https://github.com/sindresorhus/awesome
It's an interesting resource but perhaps the title of it is a little egoistic/presumptuous in that regard.
Clickbait with a lot of effort but poor delivery of title and expectations
I would love to tag HN comments with certain attributes and be able to filter them out. For example, this comment and the parent could be tagged "meta-discussion". Then those who want to discuss the content of the article could filter them out quickly.
/. tags are pretty accurate - "funny" "informative" "insightful" "trolling" - though trolling is a delete-level offense here.
Likewise, metamoderation (peer review, or moderation of tagging) was a brilliant idea.
The simplification to up and down hurts discussion on Reddit (and probably on hacker news too) because it promotes widely comprehended and accepted content. This is why on Reddit pictures do so well unless they are banned, they are very quick to review and choose to up or down vote. However a 10k document will be reviewed by a lot less people, it could fit exceptionally well with the content and get 100% upvotes but be completely buried by all the pictures because a lot less people had time to view it and upvote it.
There is a deeper challenge here with how comments and upvoting and content filtering via users is done. It isn't just the lack of information from tags but also once a document is reviewed will an upvote occur. Much of Reddit shows users will widely upvote on the basis of the title of say news without ever reading it. The longer the article is the less people will return to Reddit to upvote it. Both HN and Reddit promote popularity over fit because low numbers of upvotes on content equates to low engagement and that isn't valuable to them, but it might be the singularly most important piece of content for that audience its just long and badly titled.
There are a bunch of unsolved issues that Reddit and HN have surfaced around the model for content and comment voting and where these two sites differ is mostly only in the rules to try and mitigate the problem with the chosen model. The problem is only more complicated models can improve it and the moment you do that you potentially lose customers, but at the same time you potentially don't want those customers either.
That is my unfinished thought chain on this.
Therein lies the key paradox. Statistically, content quality usually has the shape of the the lognormal distribution, with community size on the horizontal axis and quality on the vertical. Content below a certain margin of popularity is usually unpopular for a reason--the ideas of the community are not very good! When content quality is high, the popularity of a community rises because the ideas are good! After a critical threshold though quality goes down. Once you've reached that threshold, number of users is inversely proportional to quality. I really like HN vetting process for voting: you have to have spent enough time on the site, and commented in a way that gained sufficient approval from the existing community in order to get the right to vote in that community. Keeping barriers to entry high is critical to this, but marketing people can only see $/user.
Reddit has become increasingly intolerable for me except for a few niche subreddits.
More generally, third-party annotation of web (especially hypertext) resources is an underexplored opportunity. I suspect it’s at least partly because integration isn’t a first-class concern for these sorts of apps (if it were, they’d build it themselves and own the feature and the data), so the experience isn’t that great and the marketing is significantly diluted.
> 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.
(Except, I suppose, you theoretically could implement C++ so that it also allocated every variable. Still, I think the point is valid: Haskell, by its nature, has to do things that C++ doesn't, so Haskell is going to have a very hard time being as fast as C++.)
Of course on current hardware with current compiler Haskell programs tend to be slower, and also tend to be more correct compared to C/C++ (maybe even compared to let's say C++20).
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 :)
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.
https://www.trumanlittlewhitehouse.com/key-west/president-tr...
He thought assuming that leading J made him seem more posh and WASPy
https://en.wikipedia.org/wiki/J._Robert_Oppenheimer
https://en.wikipedia.org/wiki/E_(surname) https://en.wikipedia.org/wiki/Cai_E
[1] http://www.geopatronyme.com/cdip/lettresnoms/lettres1-3.html
Edit: Funny observation - when you use the system that's linked to try and look up the public records, it won't even let you search for names with less than two letters.
https://en.wikipedia.org/wiki/C%C3%A9dric_O
That's exactly some of the cases we had to deal with some legacy invoicing systems (of which Kevin was not responsible, but I was ;))
>Heterogenous units are of no practical use. (Radar beam height formula uses a constant expressed in nautical miles per foot)
Constants in formulas can be expressed in any unit system you want. What the author means to say is that one formula they saw in one textbook used nautical miles per foot. The "radar beam height formula" is not specific to any particular unit system.
[0] https://www.stevemoser.org/posts/dev/falsehoods-programmers-...
* A property will have an address
(I live in a very rural area of CA where the roads have forked several times for many miles to get to a property and they are all unnamed private roads. People often just put down the APN and the nearest town (which might be several miles away) as their address. I deal with this one all the time. I routinely have to find their house for the first time. Good luck using GPS here, if you can't read a map, you're S.O.L. [And no, even trying to confirm that you are where you think you are with GPS on your phone is gonna be a challenge. For one, you're miles from cell reception so if you didn't save the map to your phone, you're screwed. For two, under heavy tree and cloud cover, you may not even get a GPS fix on a phone.])
* A recipient needs a name and address
My mother lived for a time in a very rural area nearby. She rode a BMW motorcycle and someone she met only briefly once successfully sent her a letter by simply drawing a BMW symbol as the name and address and affixing the nearest town.
* A person has a street address
Homeless and rural people regularly fail this one.