Falsehoods Programmers Believe In | Hacker News Reader

Falsehoods Programmers Believe In

github.com

84 pointsthunderbong61 comments

I like this a lot and it’s well worth reading over.

For a lot of programming tasks, it’s best to consider these kind of lists not as falsehoods but as edge cases or assumptions that should be made explicit.

Handling every “falsehood” gracefully yields a combinatoric explosion in the complexity of your data model. Sometimes it’s the right or ethical thing to do it anyway, but other times it’s by far easiest to document the assumption and move on.

> Handling every “falsehood” gracefully yields a combinatoric explosion in the complexity of your data model.

Sometimes this only happens if you started off with a model that made too many assumptions in the first place. For instance, regarding the "Falsehoods programmers believe about names" list, a naïve American programmer might just go with a simple pair of fields for the first and last name, running into many of those falsehoods, and if they stick with that approach, they'll have a mountain of edge cases to (potentially) handle on their hands. However, if you instead loosen up the format and just provide a single field asking something like "What name would you prefer we use when referring to you?", you avoid almost all of the "edge cases" in that list (many are so widespread that they can hardly be called edge cases) and will end up with an implementation that is even simpler than the one the hypothetical naïve programmer would have provided. Of course, this might cause some difficulty if you need to interact with external systems that require a specific format for a name, but at that point the issue is that someone else has made similar assumptions, not an inherent difficulty associated with using a less constrained format.

Often the secret is not so much to 'handle every "falsehood" gracefully', but rather to simply not impose prior cultural assumptions.

Take the names for example. Spanish naming conventions are "(given name){1,n} (first surname) (second surname)". For instance the full name of current acting Prime Minister of Spain is Pedro Sánchez Pérez-Castejón. However, for the overwhelming majority of non-official purposes, Spaniards only refer to the first surname, which in this case is Pedro Sánchez.

Now, the problem arises when Spaniards make use of software (or businesses, or bureaucracies) that have been designed based on the English convention of "(given name) (middle name)? (surname)" when parsing their full name.

If Spain's PM is asked to fill in his first name and then last name, and the system was designed with an Anglophone expectation as to how to display his name (e.g. a credit card) guess what it will be? Hello MR PEDRO S PEREZ-CASTEJON! [0]. Or maybe it's an account for an online service which generates an avatar based on "his initials". Will they be PS or PSP as he expects? No. They are, much to his chagrin, PP [1]... and there's no option to change them [2].

And if he ever has to provide his "last name" to log in to something (e.g. magazine subscription [3] or UK Council Tax authority [4]) he will be shocked with frustration at the fact that the system not only refuses to recognise the last name that he provided in the surname text box as written ("Sánchez Pérez-Castejón"), but also won't get it in pure ASCII ("Sanchez Perez-Castejon") nor just his first surname ("Sánchez" or "Sanchez")!

It is only when he finally asks his half-Spanish half-British friend for help that he's finally told the answer: "Try login in just giving 'Pérez-Castejón' as your last name" which he does successfully with a sigh of relief.

What I'm getting at, is that it doesn't take additional logic for a system to be compatible with both Angloamerican naming conventions and Spanish naming conventions—it takes less logic! All that is needed is for the system to either accept the customer data as given rather than make assumptions as to the meaning of space-separated words, or ask for the customer's preference for display. If the customer said their last name is two-words-long then that is their last name. If you need to display the full name, display it as provided. If you must use initials, let the user choose them.

[0][2][3][4] Based on true stories, only the names of the characters have been changed.

[1] "PP" is the main opposition party to the acting Prime Minister.

Indeed. Or, more generally, don't over-define your data model. Keep it as simple as possible (but no simpler.)

> Falsehoods about Names - The article that started it all.

This is a meta-falsehood in that the names programmers deal with are often mandated to have certain properties by external authorities, such as governments. For example, a programmer writing payroll software has to deal with the government because of taxes, so the government will decide what names are valid. Sometimes, as in Denmark, this means names are picked out of a list of valid names, and any name not on the list is invalid. This isn't a "falsehood" in that the Danish government is a source of truth, and cannot be wrong.

https://en.wikipedia.org/wiki/Naming_law

This same logic applies to other supposed "falsehoods" as well, in that external sources of truth can mandate properties and the code must conform. At that point, it stops being a falsehood.

(Further, if your name has a character my software can't represent, we'll have to come to some kind of agreement in order to proceed. That isn't a "falsehood" it's a basic fact of life.)

I think the word "falsehood" might be better described as "heuristic".

It's the right word, it just isn't being used in its full context.

Like, plenty of people have names not on the Great Big List Of Dane Names. Those people are not Danes, but if you want to deal with the non-Danish of the world, you have to handle names not on the Dane Names list. OTOH, thinking people writing tax software for Denmark are falling prey to a "falsehood" by not allowing someone to be named 手塚治 you're committing the falsehood of not understanding why they're accepting names to begin with.

Does Denmark not have working immigrants who pay taxes?

My point is less about Danish taxes and more about external constraints.

By all means nitpick my knowledge of the Danish tax code, though. That sounds like fun.

They're pointing out that while danish law can determine what names are applicable to some specific purposes, they aren't actually an authority on what names are valid. If you weren't being a dick about it this would actually make your original point stronger, as now your business domain logic is the intersection of danish law with actual names, a more complex case than either alone and requiring judgement and tradeoffs.

Under the Law on Personal Names, first names are picked from a list of approved names (18,000 female names and 15,000 male names as of 1 January 2016). One can also apply to Ankestyrelsen for approval of new names, e.g. common first names from other countries. Names cannot have surname character, and must follow Danish orthography (e.g. Cammmilla with three m's is not allowed).

Right but if you move from another country as an adult are you required to conform to this rule? Do you have to change your name? Do you change your name after you arrive? What are you using in the mean time? Does the state keep a record of your pre-change name?

The restriction on baby names doesn't lead into a clean authority on all names. Especially not one you can map with a sql check constraint or whatever.

If you move from another country as an adult you may need to apply to add your name to the list of approved names

> For example, a programmer writing payroll software has to deal with the government because of taxes, so the government will decide what names are valid.

(IANAL.) Hehe … but which government? (And perhaps which bureau within the government?) My birth certificate & driver's license — both issued by the same state — had different names on them. (Mostly because my state has the IQ of a rock.) (A situation I've since resolved by moving…)

But yes … prompt only for the exact bits you need to feed upstream … ideally. The problem is that PMs want the UI to be "simple".

Even today, there's no requirement that driver's license (state A) == birth cert (state B) == SSN (feds).

(Although — again, IANAL — that last one can, AIUI, only be temporarily out of sync, as there's a requirement that if you change your legal nameᵃ that you must then change your legal nameᵇ.)

(ᵃwith a state government; ᵇwith the SSA. I got no idea what the SSA does with differing legal names between states, which some states force because de jure you're not permitted to reconcile the differences. Aforementioned rock-IQ state does this.)

This is not good. Some of the time stuff is relevant if you're digging deep into it, but it's more like "uncomfortable truths we ignore for sanity." They're mostly edge cases that are unreasonable or silly to address until it's a problem.

Just listing off "falsehoods" is not a good exercise. It's literally an endless list. Some sections have no explanation and you lose context on what it is you should be learning.

More than half of what I read should just be deleted. It's not a reminder, or a lesson to be learned, or actionable

To me the point has always been of shattering the naive confidence programmers have when modeling things.

I never thought I should handle each and every case, just be mindful of the assumptions I'm making.

I got lost why 23:59:60 is valid time...

Occasionally a leap second is added or removed, to account for various sources of drifts. This leap second is taken to be the last second of the day where it is inserted, so the time technically either goes 23:59:59→23:59:60→00:00:00 or 23:59:58→00:00:00, depending on if a leap second is being added or removed.

That being said, many OSes handle this in such a way that 23:59:60 doesn't appear, either by repeating 23:59:59 (so it last two seconds), or "smearing" the extra second over the course of the day (so each second on the system clock that day is just over a second long).

Edit: I'm pretty sure I read recently that they are no longer going to be adding/removing leap seconds, although I'm not 100% sure that was a definitive decision.

The currency section is very nicely done. My own reactions split into the three obvious buckets. 1) Oh, I don't make that mistake! That's an obvious oversimplification. 2) Yeah, having read your counter-example at the end, I'll insist that I pretty much know that one, too. But thanks for the reminder, even though if I weren't skimming so fast, I'd have got it right, too. And, of course the inevitable. 3) Ouch. I had no idea. You got me on that one.

I love this list, but there was one that seemed odd.

"Time passes at the same speed on top of a mountain and at the bottom of a valley"

Unless you're writing software used to track very intense scientific measurements requiring information about time down to the sub-nanosecond, I don't see how the effects of time dilation between a mountain and valley would ever have an effect on program logic.

Everything else about time can and will bite you at one time or another.

Or airplane passengers vs those on the ground.

Something like 59 micro-seconds per 10 million frequent flier miles.

Eh, doing the math[0], it seems like you'll actually drift about 1 nanosecond every ~35 minutes if I pick a mountain near my house vs sea level. That means you'd have about 1 microsecond of difference in your clocks in about 3 weeks. For a 1 millisecond drift though, that'd take about 66 years. That's still pretty safe, but it's definitely not "you never have to worry about this˟" territory. I'm sure some others can chime in with cases where 1 microsecond clock drift (in cases expecting very accurate clocks) can cause problems.

    >>> g = 9.8 c = 299_792_458
    >>> h = 4392 # height of Mt. Rainier
    >>> drift_per_second = (g*h)/(c**2)
    >>> print(drift_per_second)
    4.789023865263744e-13
    >>> nanosecond = 1.0e-9
    >>> seconds_to_drift_one_ns = nanosecond / drift_per_second
    >>> print(seconds_to_drift_one_ns)
    2088.1081993625176
    >>> print(seconds_to_drift_one_ns / 60) # minutes till a 1 ns drift accumulates
    34.80180332270863
    >>> print((seconds_to_drift_one_ns * 1000) / 60 / 60 / 24) # days till ~1 microsecond accumulates
    24.167918974103213

[0] - http://www.leapsecond.com/great2016a/#%3A~%3Atext%3DConceptu...

DST during a running job which crosses a boundary and upstream it is 1 hour ahead of the downstream

https://hn.algolia.com/?q=https%3A%2F%2Fgithub.com%2Fkdeldyc...

More like "Falsehoods that Ted in Marketing Passed Down As a Requirement, And Your Boss Didn't Want to Hear Any Different: Why Are You Wasting Time and Resources On This Minutae? Just Do What You've Been Told."

> no currency is defined for transaction below two decimal points

[ISO 4217 would disagree](https://en.wikipedia.org/wiki/ISO_4217)

To be clear I don't think you should use floating point numbers for storing/calculating amounts;

But the irony of being wrong is not lost on me.

Green stamps used to have values in a tenth of a cent. Green stamps were never legal tender, but they were a form of currency.

https://www.nj.com/union/2017/02/made_in_jersey_sh_green_sta...

That list has several 3 and 4 digit entries, so the assumption 'no currency is defined for transaction below two decimal points' is indeed a fallacy.

Did you misunderstand the statement as being a truthy claim rather than a false claim?

It isn't phrased as a fallacy, it's phrased as an argument against using a float.

There's obviously some difference of opinion about what "below two decimal points" means. Given that they point out the 0 decimal point Yen, it seems they mean "more precise than", ie more decimal points.

Even if they meant the opposite their own example of the yen disproves that.

Is it just programmers, or is it product managers and literally everyone who wants that next feature?

These are pretty good. though far from exhaustive. The shopping section was a fun read. Half the time I was laughing out loud with compassion and the rest I was shuddering with anxiety for some of those issues to rise up in my future.....

> Price is an indication of value.

That's not a falsehood. It's true.

You reminded me of this: https://www.wired.com/2011/04/amazon-flies-24-million/

No sales took place. You can price something at whatever you want. If nobody is willing to pay that price, it does not have that value. If the price is less than you value it, you won't be willing to sell it.

Many people seem to believe in a notion of "intrinsic worth". There is no such thing. Trying to force such a thing using the law just results in a lot of deleterious distortions.

For example, when the government tries to fix the price of gold to a fiat currency, an inevitable monetary crisis follows.

I'd offer this example as counterpoint: I would not sell my dog for less than a 5-digits sum, but if my neighbor kills my dog all I'm owed is the ~$50 that it would cost to get a similar dog from the pound.

The dog's price is $50. The dog's value is much higher. See also: family heirlooms.

The value to you is much higher. The value to someone else is $50.

When two people agree on the value, an exchange takes place. That's how the Law of Supply & Demand works.

In my yard sale I might sell an ultra rare stamp for $1.

That's it's price.

Doesn't mean it's its value. It's not even anywhere close to being an indicator for it.

Might not even be due to ignorance, like in the example ("information assymetry" as the popular kids call it).

I might sell a Ferrari for $10 dollars out of spite (it belonged to my ex and I hated them). Stranger things have happened.

https://www.youtube.com/watch?v=-uYKLe2lP6Q

It's value to you was $1.

Well, that's a worthless definition of value.

There's no utility in saying something's value is $100 when nobody will give you $10 for it.

In the example plenty of people would give you $100 or even $10000 for the stamp. The person selling it and setting his price just didn't know it.

It's value to you was still $1.

You started the thread by asserting that "price is an indication of value" is correct.

I gave an counter example where someone ignorant of a thing's value (a guy who doesn't know they're selling an ultra rare stamp) sets it price to $1, wherea the market would gladly have paid 1000x times that.

You said, "It's value to you was $1".

When told it's not relevant, you said "there's no utility in saying something's value is $100 when nobody will give you $10 for it" which is about a different kind of value altogether.

While that's correct in itself, I pointed how that's not refuting my example, as my example covers exactly the reverse case: the situation where plenty would give you 10x or 1000x for what you sell at a price of $x. In other words, I gave an example where price is NOT an indication of value. That's what you had to refute.

You then backtracked to saying again: "It's value to you was $1".

In any case, value has specific meanings in economics, and neither of them is about "value to you [the seller]":

"Economic value is the measurement of the benefit derived from a good or service to an individual or a company. Economic value can also be the maximum price or amount of money that someone is willing to pay for a good or service. As a result, economic value can be higher than market value".

I.e. the value of something is different for different people.

That's basically the definition of value.

What price a seller sets for a product is based on neither of those cases.

It can be widely different from the actual market value the item could fetch (as per my example).

And it's also not the value the buyer gets ("the benefit derived from a good or service to an individual or a company"). Again in the example I gave this is many orders of magnitude bigger than the selling price.

If you interpret 'indication' broadly enough to allow plenty false positives and false negatives, then sure. But surely you would agree that a stronger formulation (high price must mean high value / low price must mean low value) would be false, yes?

> (high price must mean high value / low price must mean low value) would be false, yes?

The price the seller sets is the seller's idea of its value. The price the buyer bids is the buyers' idea of its value. When those prices are the same, and an exchange takes place, that price is the value of the item to both of them at that moment.

To me that seems complete nonsense. I have sold stuff for more than the minimum price I would have accepted, and bought stuff for less than the maximum I would have paid. This must happen all the time, and there must be many transactions where the price that ends up being paid doesn't match the value assigned by both the buyer and the seller.

Your story seems like a frictionless spherical cows in a vacuum kind of economics theory.

I once had my property assessed for quite a bit above market value. I offered to sell it to the county tax assessor for about 10% below what he assessed it at, saying that if its value was really what he assessed it at, he could make a fat profit flipping it.

He didn't take the offer.

That's what a "nonsense" value is - a price nobody is willing to part with their own money to pay for it.

Not if it's a pump and dump, or if they didn't include fees and rebates.

Fraud is misrepresenting the object for sale.

Btw, isn't the difference that price is before a transaction and value is after? You're perfectly capable of guessing wrong at how much value you're going to get out of something.

(nit) Title has extraneous word "In"

It's not even optional, it's wrong. One believes in people, causes, dogmas, etc; one believes propositions.

Dogmas are propositions.

Unicode: Every codepoint can be expressed in UTF-8.

wait can some not?

UTF-16 surrogates are code-points, but UTF-8 prohibits encoding them. However unicode strings are sequences of unicode scalar values and can't contain surrogates, so you can encode every unicode string in UTF-8.

(There is the WTF-8 encoding, which allows unpaired surrogates under certain circumstances. This can be useful for losslessly storing wide-strings (unvalidated UTF-16) in a UTF-8 like encoding, which are used by Windows, C#, Java and Javascript)

ohhh that's a fun and subtle thing. Thanks!

LLMs love these pages.

Reply on news.ycombinator.com