Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Because programmers are too lazy to properly handle long names? That's a stretch for denying someone service and you know it.

Like, yes, nobody is forced to accept their name unless they're running a government service, but using it as an excuse is just that, an excuse.



Any system will have some limit on the length of names - if nothing else, the budget for storage.

A non-lazy programmer will determine an appropriate limit, document it, continuously test that the entire system can handle that length correctly, and continuously test that helpful errors are returned when too-long names are input.


What if my legal name is 500 trillion characters long? Should every project design their storage system to accommodate this?

If you look at the 666-character name, it's no more or less ridiculous than 500 trillion characters.


Ask the government whether your legal name can be that long. They'll say no.


Handling arbitrary length input without caring how that could be abused is also lazy.

If you're working in a stack that nicely handles arbitrary lengths, it takes extra consideration and effort to put in limits.


> nobody is forced to accept their name unless they're running a government service

I dunno, would you expect that the government should be allowed to dictate how long a person's name can officially be? If yes, then problem solved, nobody may have names longer than X, and all services will accept X. If no, then there has to be a practical limit on name sizes that government services can accept, and people will be unhappy because it doesn't accept their "official" name.


Alas, that only works if you are dealing only with people under the jurisdiction of the government in question.

There's always them pesky foreigners.


There's also the fact governments aren't static. The past, and future, are foreign countries.


To be clear, I'm not arguing for or against a specific value as the "maximum length" of a name. I'm drawing a distinction here in terms of a potential user's intentional choices and what that means for providing support.

> Because programmers are too lazy to properly handle long names? That's a stretch for denying someone service and you know it.

I don't think someone should be denied service if they happen to have a long name, but I genuinely don't think it's a stretch not to try to handle people going out of their way to subvert expected norms. In this case, the argument is more philosophical than technical because there isn't an obvious heuristic for determining whether a name is intentionally made long or not, but there are places where I do think it's worth it for programmers to consider.

As an aside, I'd argue there's more nuance than "properly handling long names" or "being lazy. There's already an inherent limit on how large a name can fit into memory, and that limit might even fluctuate depending on the number of users being processed in a server at a given time and how much memory a given server has. Is a 1 GB name too long to be worth handling, or is not handling it "laziness"? If you're arguing that any name that the government accepts should be accepted by any software, how do you know what the limit is that the government will accept? If you have international customers, is the limit larger? If there's no documented limit, do you just need to hope your software is at least as robust as the government's? My point isn't that these situations are equivalent to a name that's 666 characters long, but that arguing that not handling 666 characters is lazy already is a blend of implicit technical assumptions (servers have enough memory that handling names with 666 characters isn't an issue) and social assumptions (it's possible for someone to actually have a name that long), and I don't think that "pretend all names can fit into memory fine and just crash or time out or something if there are too many names that are too long according to the parameters of the runtime and the hardware" is the obvious best choice from a fairness perspective.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: