Hacker News Reader

Hacker News

Comment by CapitalistCartr | Hacker News Reader

Parent Full thread

CapitalistCartr

This is much like Patrick's "Falsehoods Programmers Believe About Names".

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

View on HN

Also:

Falsehoods programmers believe about time:

http://infiniteundo.com/post/25326999628/falsehoods-programm...

More falsehoods programmers believe about time:

http://infiniteundo.com/post/25509354022/more-falsehoods-pro...

Falsehoods programmers believe about geography:

http://wiesmann.codiferes.net/wordpress/?p=15187

Falsehoods programmers believe about addresses:

https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...

Nice! I wish I had known about these articles before. I just created a repository to keep track of them: https://github.com/jameslk/awesome-falsehoods

Shouldn't that be 'A curated list of awesome falsehoods'? ;)

Indeed :) I updated it and made it a bit more specific: "A curated list of awesome falsehoods programmers believe."

Wish the geography one had "terrain is consistent through time"

The border is where the river used to be... total chaos now

https://www.google.com/maps/place/Vicksburg,+MS/@32.1198292,...

My pet peeve: "falsehood lists" that see no reason to explain _why_ any of the falsehoods are false.

A while back, when this came up on HN previously, I wasn't sure that all of them were actually falsehoods, so I went through each and listed reasoning for why I though they were or weren't:

https://gist.github.com/thanatos/eee17100476a336a711e

A few explanations you can add for more-falsehoods.rst:

> 15. Unix time is the number of seconds since Jan 1st 1970.

The section you quote from Wikipedia shows why this one is false: leap seconds. Similar to how the number of hours between 00:00 and 3:00 in most of the United States depends on whether the timezone remains constant, springs forward, or falls back, the number of seconds between two Unix timestamps depends on how many leap seconds were inserted or deleted in that time frame.

> 16. The day before Saturday is always Friday.

This one is true only within the assumption but I'm not sure if the falsehood is literally false. When Alaska did the calendar change it had two consecutive Fridays (October 6th & 18th, 1867). This gives us the day after Friday not being Saturday but technically not the day before Saturday not being Friday. The falsehood still holds in spirit (outside of the assumption), of course, and it's possible somewhere else had it be true in practice as well.

> 27. The weekend consists of Saturday and Sunday.

The weekend differs across the world. Friday and Saturday is another popular one but Brunei gets a special shout out for having a Friday and Sunday "weekend" with Saturday being a working day.

> 59. DST is always an advancement by 1 hour

As far as I know, this is currently true if you aren't dealing with historical datetimes but Singapore will mess you up with historical data. They had a really odd case[1] where they went on DST by advancing 20 minutes and then ended DST without changing the clock at all.

[1] http://www.timeanddate.com/time/zone/singapore/singapore?sye...

Wikipedia suggests that there's an Australian island that still uses a half-hour DST.

https://en.wikipedia.org/wiki/Daylight_saving_time#Procedure

There's a street in Buenos Aires with a name that translates to "17 of Novemeber 1894" (or some other year, not sure).

So, not only does the street have a number, it has TWO. And your address ends up being:

"17 of November 1894 230 3C" (we put building numbers after street names).

Oh, god. It's like a perfect storm for a crippling epistemological dilemma. "Nothing can be known, not even this" about sums it up. I guess we're stuck with working from probabilities. Carneades would be proud.

The point is not to include validation rules that will fail for well formed data.

Going further, if at all possible, leave validation up to others. For example, don't validate delivery addresses at all if your shipping company has a validation API.

If you must do validation yourself, put in the time to research it and get it right, don't just bang something out based on your own experience of the problem domain.

Edit: one more: if you must validate, keep this separate from how you store the data, so you can more easily fix your mistakes or adapt to changes.

So... what are we supposed to do? Every abstract model of reality has to make some simplifying assumption. Or should we curate some sort of general libraries that can handle all the exceptions to the rules if they are given enough context? Many of these libraries already exist.

This is like trying to accept all valid email addresses according to the RFC. Even when we have a spec, there's a maddeningly complex array of possibilities, but it's ok if for almost everything we accept some subset of it. It would be madness, for example, if we forced government employees of a particular country to be able to deal with all possible scripts of the world, including Prince's symbol, just to account for all possible ways that humans name themselves.

This is remarkably easy if you aren't writing an MDA/MTA: Treat the email address like a blob. The only verification necessary, if any, is whether the user clicks the enrollment link or whatever.

Also: Falsehoods programmers believe about time and time zones:

http://www.creativedeletion.com/2015/01/28/falsehoods-progra...

The same could be said about addresses. I love printing out a Fedex shipping label on-line, and then seeing how it mangles French diacritics. Then I have to hope the package will make it to the right place.

Sometimes these accents are disambiguating...

The way American (or maybe English speaking) companies handle diacritics is shameful... but don't postal codes serve as a kind of check against incorrect or ambiguous place names?

This annoys me, as I've had to deal with a lot of corrupted data. So when I moved from the UK to "København Ø" I experimented on all the change of address forms, for banks etc.

Many could handle the characters, but where I sent a paper form the person entering the data didn't know how to type it.

This must be a problem for somewhere like Armenia, where I have seen people really struggling with the English alphabet. Education was Armenian and Russian for a long time.

(There are postcodes in Denmark, but Ø is the first letter of East, so is a very broad code, in a way.)

Postal code in France is an effectively an area code (which can be quite large) so it does not help you to find the house/building, the main goal of it is to dispatch mail.

https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a...

That documents that not all addresses have postal codes. This is another example of the real world existing in order to give programmers kicks in the head.

Another good example (and mostly perl specific but not really) is Tom Christiansen's post on Unicode in perl and other languages: https://stackoverflow.com/questions/6162484/why-does-modern-...

A general list of Falsehoods Programmers Believe:

http://spaceninja.com/2015/12/08/falsehoods-programmers-beli...

Most of these are fundamentally rooted in "That understanding how to issue instructions to a computer in some way correlates with high intelligence and excellent general knowledge."

I think that's a bit harsh; it's more like "If you know how to issue instructions to a computer, you can derive anything else about the world from first principles."

All I'm really getting is "everything has a lot more exceptions than you think".

I don't think any of them about programmer hubris specifically. A lot of people could fail to realize that "23:59:60" is a valid time, for instance.

Indeed. It's not that they apply only programmers. It's that programmers are the ones who have to deal with this mess.

I actually think these lists should be called "Falsehoods designers/PO's/etc. believe about x". As a programmer, you may have to neglect these complexities sometimes, even though you know about them and have made the case.

I think some of it too is herd logic. Oh the number of times I've gotten a PM or QA to say "You should validate this field in this particular way..." and the only response to "Why?" is "Because everyone does it that way."

I'm honestly modestly happy that people can now write these articles without namechecking me for starting the meme.

Could we also add to this list "the first name comes always first ?", I expect my last name to be entered and displayed first.

Curious, are you French, Chinese or from somewhere else?

Yes, French indeed, well-spotted ! I also enter the last name in capital case, that's part of writing it like this 1000s of times in school.

By the way, for people reading this, from my own experience, at least 30/40% of French people will put the last name first in the form, whatever the text says, so to get better data, the best thing is to put them in the order (last name / first name) for them to reduce the number of errors.

Hungarian names also work like this.

Reply on news.ycombinator.com