5 ms·

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 inclu

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-believe-about-names/ http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... [2] http://loup-vaillant.fr/articles/rolling-your-own-crypto http://loup-vaillant.fr/articles/rolling-your-own-crypto

bs71721 9y ago
"Not rolling your own crypto" originally meant "do not design your own new algorithms without peer review". It is a pointless HN meme to apply this to implementing crypto (ok, the C haters here won't have a clue, but that is a given).
dqv 9y ago
>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 https://www.hl7.org/fhir/datatypes.html#HumanName
- mberger 9y ago
  May I ask where you work that you work with FHIR?
  - dqv 9y ago
    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.
_pmf_ 9y ago
> 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.
- criddell 9y ago
  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.
sbov 9y ago
I consider the names article more a thought experiment. Consider the last point: > 40. People have names. Good luck getting names right.
thephyber 9y ago
> 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}".
- thomastjeffery 9y ago
  > 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.

bs71721 9y ago

"Not rolling your own crypto" originally meant "do not design your own new algorithms without peer review". It is a pointless HN meme to apply this to implementing crypto (ok, the C haters here won't have a clue, but that is a given).

dqv 9y ago

>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 https://www.hl7.org/fhir/datatypes.html#HumanName

mberger 9y ago
May I ask where you work that you work with FHIR?
- dqv 9y ago
  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.

_pmf_ 9y ago

> 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.

criddell 9y ago
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.

sbov 9y ago

I consider the names article more a thought experiment. Consider the last point: > 40. People have names. Good luck getting names right.

thephyber 9y ago

> 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}".

thomastjeffery 9y ago
> 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.