Hacker News Reader

Comment by WayneDB | Hacker News Reader

That article seems like a bunch of useless pedantry to me.

"...refer people to this post the next time they suggest a genius idea like a database table with a first_name and last_name column."

So what's his suggestion then? Take this list of "bad" assumptions and try to build around them? Hogwash. Questioning whether you should design around someone not having a name is like asking if you exist.

I know companies that have been making millions for 15-20 years with this genius idea. You know what's so genius about it? It's simple, the developers understand it and it works for a great, great majority of cases.

View on HN

It's not pedantry when a significant proportion of people on Earth are affected by at least one of these falsehoods.

Obviously it's very difficult to design a system that doesn't fall foul of any of these, but we could at least strive for better. Just having "first name" and "last name" fields is really quite culturally insensitive. It pretty much worked when only Americans and Western Europeans were using computers, but the online world is a lot bigger now.

A comment by the author gives examples of humans who don't have names, but certainly exist: "Someone born into slavery in the Sudan, a woman born in rural China, an American baby recovered after being born into a toilet, a feral child, an amnesiac, etc, etc."

It's not quite so important for a social network to deal with this, but a government system, for example, should be more rigorous. Whatever the system, if we can be more global in our attitude, so much the better.

> A comment by the author gives examples of humans who don't have names, but certainly exist: "Someone born into slavery in the Sudan, a woman born in rural China, an American baby recovered after being born into a toilet, a feral child, an amnesiac, etc, etc."

I don't know if this is a peculiar idea, but in those circumstances perhaps a "Generate Name" button is the useful feature.

Only if that name is intended to become official. If not, rather make sure that the field accepts a null value. ;-)

I'm not going to communicate with you by pointing. Stop being a special snowflake and come up with a name, even if it's local to the service. No null values. Your name can be 'null value' though if you like, win yourself some geek points.

I think that's effectively how this is handled at the moment.

"an American baby recovered after being born into a toilet"

Does anyone seriously believe that this person will go through life with no name? There are placeholder names for unidentified people, the baby will get one of these until someone takes authority for it and names it.

It is too pedantry, when at the end of the article you're suggesting that anyone is sub-genius for simply not caring about the same things that you might! Especially when a significant proportion of developers are not going to be adversely affected by most of these falsehoods (many of which are just the same assumption worded differently).

"Obviously it's very difficult to design a system that doesn't fall foul of any of these, but we could at least strive for better."

If your goal is to achieve some nebulous goal of being "better", then sure. Otherwise, please tell me exactly why am I wasting my time? There has to be a reason, for instance if I'm building a global system that actually cares about acquiring exact/full/legal names and every name you've ever had.

"It's not quite so important for a social network to deal with this, but a government system"

There you go. You almost hit the nail on the head, but again - if your government system is not concerned with collecting every data-point about the person's name, then why should it care?

Having a full_name and a usual_referent_name would seem to work.

full_name - Matt S. Trout usual_referent_name - Matt

(for "normal" stuff)

full_name - Matt S. Trout usual_referent_name - mst

(for "geek" stuff)

and, yes, if I'm registering with a site for both, I have to pick one. But at least no matter what my full name is that way I can enter it.

It's impossible to design around them, given that several of the items are mutually exclusive.

The point of that article is not to define any definite solution; it's just to remind the programmers that there is a nonzero number of cases when any of the assumptions on the list (and any that are missing) will be wrong. Of course that one should cover most and not all cases, but they should be flexible enough to anticipate a surprise of that kind.

have an upvote from someone with a single surname living in a country where the default is to have two...

"Just a reminder"...sure. It's funny how "just a reminder" always sounding patronizing, particularly when there's no good solution that covers every base.

Not only is the tone super pedantic, but the author berates people for creating simple databases based on their simple assumptions.

Fuck that. Not very agile. It's not like we can't update it if there's a large demand for change in the way names are collected.

I have a one-word legal name.

Some people have two, three or more names.

Now what?

Put the name you like in 'First' and anything remaining in 'Last', it'll work well enough.

I usually use the same name in both fields. My question was more rhetorical to the person I responded to.

Should I care? If I am designing a system that requires only a full legal name...then it depends on the law of the target region. If it's for almost anything else...I'm not going to waste my time unless there are more than a few complaints.

My entire point here is that if it's really important to the system being designed, that the correct answer will occur to you naturally. Honestly, if we design a system that requires full legal names and we don't look into the laws of the target region, then we're probably not too bright.

So tell me, is two names United States, or any US state's law, or is it just a common assumption?

Do programmers routinely look up the law for common assumptions? I'm guessing no.

And by the way, the tone of your responses in this thread is the first time in my years of HN participation (under various user names) that I've wished for a plonk file. Everything you've said has the core of a relevant argument, wrapped in condescension.

You're missing my point. If the legal exactitude of the name is relevant to some functionality, then yes I do think that most decent engineers will naturally tend to want a reference of some sort. Otherwise, they just change whatever broken thing they did if and when it becomes a problem.

It doesn't make them any less intelligent than the author of this article. The cutesy way that list was written and that comment at the end of the article was what I was responding to earlier, but anyway...what exactly did I say to you or anyone else that was so condescending? I'm not saying that I'm not slightly intense at times, maybe I ask a lot of rhetorical questions... Sorry.

My apologies.

What you need is to separate components of a name that can be used separately. If your app wants to say "Welcome John" in some places and "How can I help you Mr. Smith" in others, you need to have FirstName and LastName fields. If you also want to say "Account details for John A. Smith" then you need another FullName field.

You can't have just FullName, because parsing the name for it's components is incredibly complicated. (E.g. some people have last names with spaces in them.)

A suggestion below says FullName and PreferredName, which would probably work for many applications.

Reply on news.ycombinator.com