Started to read, was interesting, but then I scrolled, and the whole page seems broken. Life's too short to deal with that nonsense.
Something is terribly wrong with scrolling on that page.
For me scrolling just doesn't work at all...
Falsehoods programmers believe about names – with examples (2018)
61–70 of 115 posts
Re: Falsehoods programmers believe about names – with examples (2018)
#62In some countries, women have different last names than men do. Eg. in macedonia, traditionally a person would get their fathers name as their surname (so if the fathers name was "Petar", and the son was Dragan, the lastname would be roughly translated to "Dragan of Peter"). Because there are different forms for feminine and masculine words, The son would be named "Dragan Petrovski", and the daughter (Eg Marija) woul…
This is the case in many countries. Nordic countries do this too (...-son and ...-dottir etc.) And FWIW, in Quebec, women are not allowed to take their husband's last name when they marry. They choose for the kids.
Re: Falsehoods programmers believe about names – with examples (2018)
#63Lots of previous discussion when this was new:
Re: Falsehoods programmers believe about names – with examples (2018)
#64Earlier quoted context omitted.
> What do you want me to do about it? When you write code that accepts names, don’t bake in assumptions that violate these falsehoods.
Or do, and just don't care that Elon Musk's kid won't be able to use your application
You're being obtuse. Everybody can still use the application. The just need to supply a name that is valid to the application. THIS IS REASONABLE
Re: Falsehoods programmers believe about names – with examples (2018)
#65Programmers need to learn from bureaucrats of the 19th century. When bookkeeping of the people truly became a thing in the 1800s, industrialised nations sent out bureaucrats to collect the names of people in villages. Unfortunately, people seldom had enough names to fill in the forms the bureaucrats had. The idea of a family name was not something bestowed to nor necessary for a lowborn. If you're the only Jack in to…
[deleted]
Re: Falsehoods programmers believe about names – with examples (2018)
#66Gotcha. Un-validated unicode text boxes for names in forms from now on. After all, someone could be named like the contents of a 64MB binary blob. Compromises are unavoidable in web development.
Unicode text boxes with no validation other than a (generous) length limit and unicode validation is exactly the right approach. Arbitrary assumptions and limitations littered throughout the code is not.
Yes, and to be perfectly clear don't have a minimum length (either empty or nullable) and make it mutable, in any case where you're doing some form of soft identification (e.g. "Hi, $NAME, here is your reservation" or "I am calling from $COMPANY, may I speak with $NAME?")
Also, tell me what the purpose you're using my name for, e.g. "Name as it appears on your payment card/passport/ID/SSN" helps tremendously in resolving ambiguity.
Also, consider not asking for a name at all unless there's actually a good reason.
Re: Falsehoods programmers believe about names – with examples (2018)
#67Programmers need to learn from bureaucrats of the 19th century. When bookkeeping of the people truly became a thing in the 1800s, industrialised nations sent out bureaucrats to collect the names of people in villages. Unfortunately, people seldom had enough names to fill in the forms the bureaucrats had. The idea of a family name was not something bestowed to nor necessary for a lowborn. If you're the only Jack in to…
> If you're the only Jack in town, why bother with any other name than Jack?
In Le Guin's The Dispossessed [1] people on the satellite planet called Anarres get assigned an unique mononymous [2] name at birth. No one else alive at the time has the same name (and usually the name isn't re-used for a number of years). The protagonist is "Shevek".
Re: Falsehoods programmers believe about names – with examples (2018)
#68The altered scroll on this site is rough.
Re: Falsehoods programmers believe about names – with examples (2018)
#69Earlier quoted context omitted.
I think that part is pretty easy to understand, but if the author's intention is to have every single one of these issues addressed they're going about it the entirely wrong way.
I’m not sure anyone, including the author, considers addressing every one of those to be possible. But they want you to be aware of the assumptions you’re baking into your code, and maybe spend a few moments about which requirements you actually require. What do you think would be a better way of going about it?
> What do you think would be a better way of going about it?
I suppose it depends on what you're trying to accomplish. This article definitely reads like it's trying to annoy developers to the point of closing the page though, even if it's intentions are relatively agreeable. I'm reminded of the whole 'master vs main' debacle, where this kind of tribalism hit critical mass. There was huge potential for people to have a good discussion about acceptable practices in software development, but we gave it up in lieu of tribalism and us-vs-them politics. As a result, there was way more media blowback than necessary, which lead to a false sense of urgency and a whole lot of bugs.
So, I don't know. But I do know that a good discussion doesn't start with 40 theses and a hostage situation.
Re: Falsehoods programmers believe about names – with examples (2018)
#70Earlier quoted context omitted.
I’m not sure anyone, including the author, considers addressing every one of those to be possible. But they want you to be aware of the assumptions you’re baking into your code, and maybe spend a few moments about which requirements you actually require. What do you think would be a better way of going about it?
> What do you think would be a better way of going about it? I suppose it depends on what you're trying to accomplish. This article definitely reads like it's trying to annoy developers to the point of closing the page though, even if it's intentions are relatively agreeable. I'm reminded of the whole 'master vs main' debacle, where this kind of tribalism hit critical mass. There was huge potential for people to have…
Most of these issues can be solved by simply providing a "Name" field that accepts Unicode and has a reasonable length. Don't validate it in any way except to require at least one non-whitespace character. Trim any excess whitespace and run the text through a Unicode normalization algorithm. At most, filter out Unicode blocks that can't possibly apply, such as emoji and maths symbols.
Done.
That covers something like 90% of the already pretty obscure corner-cases. The remainder are likely out-of-scope, such as children that have not-yet-been-named. They can't legally sign up for things in most (all?) jurisdictions, so it's not really worth considering in most scenarios.
This is already 10,000x better than ascii-only input fields for "Surname" and "Given Name" limited to something like 20 characters each. Where entering "Null" or "O'Neill" throws a HTTP/500 error because JSON is "so simple" that anyone can use it...