Printing out a list of "falsehoods" littered with personal opinions and calling them "demonstrable"  without a shred of evidence is not going to contribute to general knowledge. There may be some utility in getting me thinking, but for the most part I just find it self-aggrandizing. For what it's worth, I do find this  format much more helpful. I'd very much rather see valid counterexamples proving a sweeping statement false than yet another sweeping statement that happens to cover a few sweeping statements.
Of course, the above is my personal opinion and may not be shared by the rest of the community, but please can we do better than curating a list of lists we agree with?
Even aside from the politicized content, I found it jarring that this bounced between clear and 'demonstrable' statements and entries like "you do not need a postal address", which was just a Twitter link to some letter delivered without one. It's not how I'd prefer to see this stuff curated, either.
What am I missing here? Any lossless compression algorithm works, even "string.reverse" would apply.
Like, I've had the situation of seeing a poorly-marked name string and going "I think that's 'Last, First' formatting, but I'm really not certain..." Or if you do any formatting change you'll get bizarre problems like apostrophes becoming directional quotes.
But yes, the rule-as-written isn't right, and I'm not sure what was meant.
Like transform "Mister" to "Mr"
Always ask the question you actually mean to ask.
Frequently someone's /name/ is part of a mailing ADDRESS. You can, and maybe should, limit this to a individual lines. However the only way to be SURE is to give an actual freeform multi-line input box, like a textarea.
If you want a string to greet someone as, ask for that, and store it separately.
If you want a title to display within a directory listing, accept that.
Generally, do not decompose things for your users, EXCEPT possibly client side while populating form elements for their convenience (and verification/correction).
(As for the specific question, postal addressing is fascinating. Someone in my family has an unusable address with an alphanumeric house number, and Amazon won't ship to it. And in the last one of these threads, someone mentioned living in a country which uses standardized directions-from-landmark as a formal address!)
Which was delivered to John Underhill, Andover, Mass. Unlikely to be true, but a great story.
Citation needed. I've sent mail all over the world, and the only place I've seen where you can get away with that is Ireland. It's actually famous for this. Unless you're talking about some really backwater developing nations, every nation I've sent mail to does require an address line of some kind. However, in the UK, there are a lot of funny-looking addresses in the more rural areas. They have an address line, but it's really just the name of some hamlet or house or something, then they give the name of some farther-away but larger town, and finally the name of some main town/city where the mail is first routed. But they also have a detailed postal code that can route things by itself. Out of reasonably-developed nations, Ireland is the one that really stands out for having an antiquated postal system, but it does seem to work fine for them. It's also different and more modern for addresses within Dublin, where they do have a (very short) postal code.
The only other place where I've seen a place where you don't need a street or house number is for addresses at Kibbutzes in Israel.
Or, for a rarer subcase where the person genuinely has no name at all - consider "feral children": https://en.wikipedia.org/wiki/Feral_child
This works great until property Y is violated... or until you run into one without "an X". Most times you are better off to just start with unique identifiers and avoid breaking logic.
Also of course if you give your child a name that is not recognized as a name by the name register there is a process for okaying that name, so in that case your child can have a name in the family but not an official governmental name yet.
Our daughter was "Baby Girl <Mother's Last Name>" in the EMR system for a few days even though no part of that was her name and that isn't the last name she ended up with.
A bit of an orthogonal example to the thread, but I ran into an issue like that, with a solution that worked just like you described. I was using msgpack in Python 3 to send data to the browser in JSON format.
msgpack in Python 3 decodes into bytes, as (hopefully) expected by Python 3 users.
Except the data was somewhat arbitrary in terms of how it was organized or what was included (but was predictable in type), so decoding it was a bit of a pain. The problem of course was that my strings were wrapped in b'', and that was being sent to the browser, causing the JSON parsing in the browser to fail.
My first two attempts were recursive algorithms that would try and decode strings and skip everything else (we only worked with strings and numbers, or lists of strings and numbers, hence "predictable in type"). Both times it almost worked, but didn't. Even with predictable types of data, I had to try and cover a number of edge cases.
The solution that ended up working 100% of the time in my particular case was just using regex to remove the occurrences of b'' from a string version the object, then send that as JSON. Looked like an ugly hack, and probably was, but it damn sure worked like a charm. It was much easier to just ensure I built a valid dictionary before encoding it with msgpack rather than try and "properly" decode all the strings after decoding it with msgpack.
If parents get offended by this straightforward default-naming algorithm, the recommended workaround is to name the baby.
(I have seen a different protocol: state ID number is assigned after birth, parents choose name independently of the process, the two are only linked ex post)
We're currently in Phase 1 of the project. Which is all about collecting, in the wild, instances of this trending writing style.
Now if it get traction and grows out of a gimmick, and if Falsehoods articles become a new literary form in its own right, then maybe we'll have enough resources in the community to start Phase 2. Which might see more curation happens, as well as writing guidelines and add more structure.
But besides that, for stuff that is actually empirically testable and relevant it would be nice to put them into a unit-testing library to automatically check certain functionality you build (for example to check functions that deal with time or dates or names).
"Postulates I choose to consider as universal and objective truths as to silence any discussion or debate around them"
"List of opinions I have that are facts by virtue of being on this list"
Of course, you're wrong for disagreeing with OP.
It's kind of frustrating.
Typo? or Freudian slip :)
Semantically believing something is false != I didn't take it into account.
IOW, there's a difference between "everyone has two names, so you can assume that schema for a database" vs "all women in tech are designers". The latter is false, but it's not a programming error. The stuff on this list  does not fit the pattern of programming errors.
Because from where I'm standing, if you e.g. implement gender as binary, you're not being more objective, you're just supporting the opposite side of the people you perceive as activistic.
Woah, what? Like, they're talking about effects of relativity because someone is traveling "faster" as the earth spins at the top of a mountain?
The short version is that this guy hauled three cesium atomic clocks up a mountain while on vacation with his kids. They returned 23 ns older then the guy's wife (who stayed home to study for her nursing board exams).
Note that time dilation isn't just caused by motion (special relativity), but also by proximity to a gravity well (general relativity).
If you are operating on very small time scales, or if you're going to be around a long time, it can matter a lot.
GPS devices also have to account for relativity , so programmers working on those also have to factor that into the logic.
Of course, that's the sort of domain-specific demand that might not belong in a general-use list. People writing sound engineering software have to worry about all kinds of subtleties with sample rates and harmonics, but I wouldn't put that in a guide to basic data I/O - I might not even put it in a basic analog-to-digital guide.
Example: Partner says "Don't buy the red one", then a few days later you go and buy the red one, while you should have bought the blue one. It would be better if your partner had said "Buy the blue one".
In practice such email addresses are not possible in many server configurations, and it usually makes sense to reject such email addresses.
I would put more weight on closing the loop than filtering on the front end. I'd wager that the vast majority of sites that gather an email address do not send a verification email that bars further progress on their site. It's especially critical if it becomes the underlying trust mechanism for your site.
IMO you should only work on filtering fancy quotes out if you've already got a loop-closing verification email path. And yes, I recognize that it's really nice to catch these errors earlier. But the failure mode where people enter someone else's valid email address rather than their own is more common than you might assume.
If the question involves the use of the non-ASCII quoting style, the answer is more muddled. RFC 6531 generally repeats the RFC 5321 mantra of "don't interpret the local-part", prohibiting only ASCII C0 control codes explicitly . RFC 6530 suggests that C1 control codes should also be prohibited, and suggests that non-NFC is highly likely to cause problems. It further suggests that NFKC-normalized and excluding punctuation and whitespace is risky.
In general, a lot of email address handling advice requires ignoring what the dictums of the RFCs state. You should treat email addresses as case-preserving (i.e., compare ignoring case but don't change the case), and it's inadvisable to have a case-sensitive email server. Similarly, quoted local parts and domain literals should be rejected by almost all software that's not in the guts of the email system. Extending similar rules to EAI is difficult because it's unclear how the system will work in practice, but my libraries start by force-converting the localpart to NFC.
 The actual text is "ASCII graphics or control characters." This could be interpreted to mean "(ASCII graphics) or (control characters)" or "ASCII (graphics or control characters)." Given the text of RFC 6530, assuming that C1 is forbidden should generally be a safe assumption.
My question was actually about the fancy quotes; I found it amusing that they got fanci-fied by the blog software.
Per RFC 6531 (SMTP Extension for Internationalized Email), this is not a valid address either.
Also look at Manhattan/taxicab geometry. When you can only move along one axis at a time, you usually can't move in a straight line between two points.
Both of these situations have common applications in the real world. For example, in mapping and navigation.
Also, taxicab geometry: https://en.m.wikipedia.org/wiki/Taxicab_geometry
It doesn't mean that there is a viable route on that line or that that line is the preferred one.
That one is really bad, imo
On the surface of a sphere, the shortest distance between two points is along a great circle route (which is the equivalent of a line in spherical geometry). Polar map projections preserve straight lines as great circle routes, but, e.g., Mercator projections do not.
If you're looking at a 5 km × 5 km topo map, the difference isn't particularly significant. If you're looking at a map of Europe or the United States, it is (note that many airline routes seem to follow curved lines--it's because the shortest distance is that curved line).
For regional maps it doesn't particularly matter, the map will be in a projection that has relatively minimal error, but a straight line in most projected coordinate systems will not be the shortest path between those points.
Even on maps it is true.
>"Falsehoods programmers believe about names"
>"People have names"
Is this a joke?
We detached this comment from https://news.ycombinator.com/item?id=13637838 and marked it off-topic.
> We're only in tech to find a husband, boyfriend or generally to get laid.
If you flip the genders around I'm pretty sure that would be true for quite a few men (at least the last part).
Maybe not directly (i.e. literal rock star) but as a means to an end sure.
> All civilization was just an effort to impress the opposite sex.