A lot of these so called "falsehoods" are just design failures on the part of programmers. Someone did it badly first, and it stuck, and a second person came in later and is surprised by the bad design. That's not really interesting, it happens all the time in software. So much so that seasoned engineers have come to expect poor design until proven otherwise.
Things like flight numbers not having reasonable semantics, or conceptual pollution of what a flight is to include multiple take offs and landings are bad design, plain and simple. Just model the problem correctly e.g. maybe a Trip is multiple Flights, or Flights have multiple Legs. This isn't aviation specific. These are generic problems that programmers can and should get right.
Some of it is intrinsic to the domain, like flights not all having gates, or not landing at airports. That was a new tidbit for me.
The claim isn't that programmers go around literally believing falsehoods about a given domain. The whole point of the "falsehoods programmers believe about X" genre is a tongue-in-cheek way of listing the kind of bad design assumptions that happen in a given domain, and I believe that is very interesting indeed.
The fact remains that software that models real-life events or information is making normative assumptions about what can and cannot happen in the domain, due to the very nature of software, and these assumptions are knowingly-or-not being introduced by programmers. If for any given domain we had hundreds of human notaries, scribes or typists managing information instead of software, their mistaken assumptions wouldn't matter—they would simply go "Oh, that's odd", make the necessary adjustments, and learn from the experience. But as long as software is a prescriptive model of what it is representing, it will be valuable to highlight the "falsehoods" that its creators may accidentally prescribe into it.
the point of the article (just as with the one about names) is that there are "reasonable defaults" many people would believe - that don't work in practice and become gotchas
whether you have enough knowledge to know that something is unreasonable doesn't mean it doesn't seem reasonable for many others
And as programmers, we inevitably spend most of our time dealing with these weird edge cases, because the stuff that makes sense is generally incorporated into our initial modelling and becomes a solved problem.
It does. The distinction between a misunderstanding of aviation, or a misunderstanding of which of many possible models is in place.
I'm interested in misunderstandings of aviation. How did aviators think about it before software ever entered the picture? Which of their concepts are coherent, and why do they use them? What reasoning power do those concepts get them? It's interesting when programmers misunderstand that.
It's less interesting when programmers setup a poor system for keeping track of things. It could be busses or trains or parts in a factory. It's not aviation specific, and it's run-of-the-mill bad design when it's done badly. Apparently the first software engineers to model aviation were really bad at it.
Many of the points in the article, including some in your examples, pre-date programmers and programming entirely. Still more emerged before widespread use of computer automation in aviation.
Like, sure, a better data model would be great. But switching to one is largely a human system migration effort, not a software problem.
Programmers did not build the aviation industry, it evolved over more than a century of flight, many of these conventions predate computing in aviation. Much of the lack of convention is just that the real world is pretty messy. A programmer trying to make a rigid system will struggle to account for the fact that, sometimes real world humans/events won't follow their codified rules.
Things like flight numbers not having reasonable semantics, or conceptual pollution of what a flight is to include multiple take offs and landings are bad design, plain and simple. Just model the problem correctly e.g. maybe a Trip is multiple Flights, or Flights have multiple Legs. This isn't aviation specific. These are generic problems that programmers can and should get right.
Some of it is intrinsic to the domain, like flights not all having gates, or not landing at airports. That was a new tidbit for me.