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