Hacker News Reader

Comment by bitshift955 | Hacker News Reader

Very glad to see "Falsehoods Programmers Believe About Names" included in this list [1]. I still struggle to always get this right.

One thing I'd suggest including is something about not rolling your own crypto in the security section. Does anyone know a canonical article for this? I've got [2] bookmarked but not sure if a guide with the pitfalls of designing your own crypto scheme is right for this list.

[1] http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...

[2] http://loup-vaillant.fr/articles/rolling-your-own-crypto

View on HN

>I still struggle to always get this right.

I really like the FHIR Human Name data type[0]. It requires none of the fields... so it can represent someone without a name. It also has all the necessary fields for representing someone's name and their name in various forms and pretty much as many edge cases as possible.

The only problem is turning it into a UI that makes sense.

[0]: https://www.hl7.org/fhir/datatypes.html#HumanName

May I ask where you work that you work with FHIR?

I was helping someone with an appointment reminders implementation. I was googling how to communicate with practice management systems, came upon HL7, and then FHIR.

I don't do anything "real" with FHIR at my company, I just borrow concepts because FHIR does a pretty good job at encapsulating the healthcare domain.

I consider the names article more a thought experiment. Consider the last point:

> 40. People have names.

Good luck getting names right.

> Falsehoods Programmers Believe About Names

So if you take these to heart, even a tiny weekend project will take near infinite time to handle all of these cases.

It would require infinite space, every possible supported character set, a massive fuzzy-logic search engine, etc.

Humans handle complexity by avoiding it until it becomes a pressing need. The first pass at understanding is always an oversimplified model. Usually we make additional passes, hopefully with progressively more nuanced and educated models.

Knowing that your system will run into problems in the future is sometimes enough. Deferring problems until they are actually significant business impacts is a reasonable strategy.

This applies to "Falsehoods Programmers Believe About {Names, Addresses, Phone Numbers, etc}".

> even a tiny weekend project will take near infinite time to handle all of these cases.

A "tiny weekend project" assumes, by definition, a tiny userbase. The point is to assume nothing about a dataset, because even dozens of seemingly reasonable expectations about names are wrong.

The point of the article is not to tell you to immediately write perfect code, but to make you aware of your code's limitations.

> Very glad to see "Falsehoods Programmers Believe About Names" included in this list [1]. I still struggle to always get this right.

In the real world, you'll constantly have to interact with external or internal systems that are based on the "wrong" concept, so implementing it "right" makes your system really awkward to work with.

The same was true about Unicode text not too long ago. If we don't start trying to do things correctly, we will never get to a better place.

Reply on news.ycombinator.com