"Falsehoods "falsehoods programmers believe about falsehoods" blog posters believe about "falsehoods programmers believe about "falsehoods programmers believe about logic" blog" falsehoods"
Bit of a rant: what annoys me about these lists is how they just give off a huge "you are dumb for making any assumptions, how could you not think of <extremely obscure edge case>" vibe. I'd be interested to see what the effects are of these assumptions failing, because often they are pretty reasonable assumptions for a reasonable subset of the universe. Software is imperfect and you can't cover every possibility. Like ok technically 10 flights with the same number could leave the same gate at the same time, but if 99.99% of the time they don't and you assume that, what is the real impact to people?
Reminds me of a list that came up ages ago that presented an assumption of "X code always runs" with the counterpoint that you could unplug the computer. Ok sure, but then why write software at all? Clearly no point assuming any code will ever run since you can just terminate the program at any random time.
I don't agree that this list has the attitude you describe--if anything, they just seem proud that they have many fewer of these corner case bugs than anyone else--so it is difficult to work with your example of the flight number. These are, in fact, misconceptions made by programmers, often without having the in-depth knowledge of this specific area that comes from being an actual expert (the kind that often people don't allocate for in their budgets), and this list isn't an over-the-top portrayal of such: it feels weird to become offended?
That said, I do appreciate some of these lists--which maybe has put you on edge to the paradigm--do have an edge to them... but, in all honesty, I think they should? The bugs and edge cases that these lists tend to expose aren't random glitches that equally affect every user: they usually segment users into the ones whose lives "follow the happy path" (which often just means "are intuitive and familiar to the culture near the developer") and the users who get disproportionately (or even continually!) screwed every time they dare interact with a computer.
And like, it is actually a problem that the other side of this is almost always a developer who doesn't really give a shit and considers that user's (or even an entire region/country's) existence to somehow be a negligible statistic not worth their time or energy, and I really do think that they deserve to take some flak for that (the same way I try to not get offended if someone points out how my being a cis-het white male blinds me to stuff: I think I deserve to get held to task harder by frustrated minorities rather than force them to be nice all the time in a world that penalizes them).
I don't disagree with you at all. My point was more like what another commenter said, that software adheres to a strict and very finite set of rules, the real world is way more complicated than that. It's so trivially easy to find real world counterexamples to just about any software that it's a barely interesting exercise (IMO). So you define a reasonable subset and work with that. And the reasonable subset is probably defined by positive/negative outcomes.
It would have been cool if the blog post discussed those outcomes so we can reason about it properly, otherwise it's just a list of claims at face value. If the programmer making an assumption means a screen at a gate says the wrong boarding time when there's a human there controlling the boarding, then not the end of the world. But if the programmer making an assumption causes 1/10000 flights to crash, then that's interesting and worthwhile calling out. It's just endless speculation without a proper outcome to tie it down.
At a general level I think these lists make developers more aware of uniqueness and constraints.
When designing data I think these questions (skepticisms) should be front of mind;
1) natural values are not unique.
2) things identified by number are best stored as a string. If you're not going to do math on it, it's not a number. That "customer number" should be treated as "customer id" and as a string.
3) be careful constraining data. Those "helpful checks" to make sure the "zip code is valid" are harmful not helpful.
4) those tiny edge cases may "almost never happen" but they will end up consuming your support department. Challenge your own assumptions at every possible opportunity. Never assume anything you "know" is true.
It's hard to measure time saved, and problems avoided, with good design. But it's easy to see bad design as it plays out over decades.
And (especially today) never optimize design for "size". Y2K showed that folly once and for all.
This implies denormalization, which is rarely needed for performance, despite what so many believe. Now you’ve introduced referential integrity issues, and have taken a huge performance hit at scale.
> 3)
I mean, maybe don’t try to use a regex on an email address beyond “is there a local and domain portion,” but a ZIP code, as in U.S. only, seems pretty straightforward to check. I would much rather have to update a check constraint if proven wrong than to risk bad data the rest of the time.
> never optimize for size
Optimize for size when it doesn’t introduce other issues. Anyone working on 2-digit years could have and likely did see that issue, but opted to ignore it for various reasons (“not my problem,” etc.). But for example, _especially_ since Postgres has a native type for IP addresses, there is zero reason to store them as strings in dotted quad. Even if you have MySQL, store them as a UINT32, and use its built-in functions to cast back and forth.
>It's so trivially easy to find real world counterexamples to just about any software that it's a barely interesting exercise (IMO).
These lists hopefully make programmers aware that a lot of their assumptions about the real world might be wrong, or at least questionable.
Examples are assumptions on the local part of email addresses without checking the appropriate RFCs. Which then get enshrined in e.g. JavaScript libraries which everyone copies. I've been annoyed for the last 30 years by websites where the local part is expected to be composed of only [a-z0-9_-] although the plus sign (and many other characters) are valid constituents of a local part.
Or assumptions on telephone numbers. Including various ways (depending on local culture) of structuring their notation, e.g. "123 456 789" versus "12-3456-89" where software is too dumb to just ignore spaces or dashes, or even a stray whitespace character copied by accident with the mouse.
And those forms where you have to enter a credit card (or bank account number) in fields of n characters each, which makes cut/copy/paste difficult because you notes contain it in the "wrong" format.
So while some examples may count as "just usability" it all stemps from naive assumptions by programmers who think one size fits all (it doesn't).
I disagree, in my view they do not inherently give off such vibes at all. In this post for example, they specifically broach the topic like so:
> There are a lot of assumptions one could make when designing data types and schemas for aviation data that turn out to be inaccurate.
Sounds like a pretty explicit acknowledgement of the notion that these are otherwise reasonable assumptions that just happen to fail when put to the test, I'd say.
It's very easy to self-deprecate, especially if one has insecurities. But that doesn't mean that articles like this actually mean to do so. I think it's worthwhile for everyone involved to always evaluate whether the feeling is actually coming from the source you're looking at, or if that source just happened to trigger it inside you. More often than not, in my anecdotal experience, it's the latter.
I'd also find it interesting to learn what happens when these falsehoods nonetheless make it into an implementation though.
> I'd be interested to see what the effects are of these assumptions failing
Mostly confusion, but the combination of aviation and confusion can be dangerous and even deadly. Not directly related to this list, but I'm reminded of [1]: no one entity has set out to inconvenience the hapless traveler, but the combination of history and practice are a constant source of irritation, and at the times of heightened tensions and security might even lead to scary incidents. All because of the name.
This feels like an unnecessarily defensive take. I think these lists are more meant to be humor or thought-provoking. If anything, I think they serve to point out to non-programmers why programming is difficult, not to call programmers stupid.
Surprisingly little real information in this article. It could be summed up as "use noise reduction, tone curves, and local contrast" without need for further waffle. Smells a bit like blog spam.
What I would've found helpful would be a discussion of proper exposure for astrophotography, which oddly enough was missing. If your exposure is screwed then your edits will be screwed too. They mention pulling back the star highlights and boosting darker areas, well it would be interesting to hear the author's opinions on the optimal exposure settings to enable those edits without excessive noise or clipping.
Also my pet peeve, getting colour science technicalities wrong. "RAW files are dull" no RAW files are simply not viewable as-is and any attempt to display them without proper tone mapping is pointless. "Linear image" - what does this even mean? No respect for the colour pipeline :(
You are completely right mcdeltat. The problem with writing content is that without feedback it is easy to forget or miss something, even if it appears to be very obvious to you sometimes it is just too easy to miss. A webpage needs to be constantly updated.
On the point of fake bokeh, as a photographer I can't stand it. It looks horribly unnatural and nothing like bokeh from a good lens. Honestly astounding people think it looks good.
If you want a pretty portrait, just buy/borrow a cheap DSLR and the resulting image will be 100x better.
I have a camera with some primes and love those portraits. That said, the fake bokeh keeps getting better. With the iPhone 16 Pro it‘s now good enough that i no longer find it to be an issue.
> I remember often being “stuck” on some concept (usually in biology and chemistry), where the teacher would hand-wave something as truth, this dismissing my request for further depth.
This resonates with me a lot. I used to dismiss AI as useless hogwash, but have recently done a near total 180 as I realised it's quite useful for exploratory learning.
Not sure about others but a lot of my learning comes from comparison of a concept with other related concepts. Reading definitions off a page usually doesn't do it for me. I really need to dig to the heart of my understanding and challenge my assumptions, which is easiest done talking to someone. (You can't usually google "why does X do Y and not Z when ABC" and then spin off from that onto the next train of reasoning).
Hence ChatGPT is surprisingly useful. Even if it's wrong some of the time. With a combination of my baseline knowledge, logic, cross referencing, and experimentation, it becomes useful enough to advance my understanding. I'm not asking ChatGPT to solve my problem, more like I'm getting it to bounce off my thoughts until I discover a direction where I can solve my problem.
Different .c/.cpp files being a barrier to optimisation always struck me as an oddly low bar for the 21st century. Yes I know the history of compilation units but these days that's not how we use the system. We don't split code into source files for memory reasons, we do it for organisation. On a small/medium codebase and a decent computer you could probably fit dozens of source files into memory to compile and optimise together. The memory constraint problem has largely disappeared.
So why do we still use the old way? LTO seems effectively like a hack to compensate for the fact that the compilation model doesn't fit our modern needs. Obviously this will never change in C/C++ due to momentum and backwards compatibility. But a man can dream.
(Back in C++20 days I had a terrible habit of finding bugs in MSVC's implementations of metaprogramming features, after they claimed to be feature complete on C++20. Probably because people use these features less. Even now I occasionally receive emails about those bugs they've finally fixed.)
I always wondered why constexpr needs to be an explicit marker. We could define a set of core constexpr things (actually this already exists in the Standard) and then automatically make something constexpr if it only contains constexpr things. I don't want to have to write constexpr on every function to semantically "allow" it to be constexpr even though functionally it already could be done at compile time...
Same story with noexcept too.
One reason which matters with libraries is that slapping constexpr on a function is, in a way, a promise by the author that the function is indeed meant to be constexpr.
If the author then changes the internals of the function so that it can no longer be constexpr, then they've broken that promise. If constexpr was implicit, then a client could come to depend on it being constexpr and then a change to the internals could break the client code.
Anyone else getting concerned about the rate of development of the C++ Standard vs compiler implementation? We don't even have feature complete C++20 on the major compilers yet. C++23 is even less implemented. How will the committee handle this? Will they reduce feature additions at some point in the future?
FWIW, I can’t ever remember a time when the most widely used compilers in practice weren’t around 5-10 years behind changes in the standard. Part of the issue is that adoption takes time, and always will. A lot of people using C++ professionally don’t want to be on the bleeding edge of language changes. Some do, but a lot don’t, for good reasons.
When I was in college in the 90s, templates were new and had iffy support. In the 2000s, STL was still problematic. I remember the Microsoft Compiler spitting out error messages on STL types that were so long the compiler couldn’t handle the string length and truncated the error message so you couldn’t see what the problem was. In the late 00s and early 10s I worked in games, we wanted stability and for the code to be as non-tricky as possible (for example by banning use of exceptions, STL containers, and most casual heap allocation, among other things.) So we used older compilers by choice. My current job publishes an SDK and APIs that people have been using for many years, they need to be backward compatible and we can’t impose recent language features on our users because not everyone uses them, we have to stick to features that compile everywhere, so I still see lots of C++{11,14,17}.
Perhaps you are right, and I had rose tinted glasses. I seem to remember C++17 being completed (all major features) around 2018 on at least one or two major compilers. Meanwhile C++20 still doesn't have modules properly implemented, which is such a huge feature IMO that I count it as a major deficit. But maybe C++17 was the exception rather than the rule.
I think what annoys me most is when a standard is implemented except for an important feature. E.g. ranges was unusable for ages on Clang. And modules is still not quite there. I want to use the latest standard to get these cool features so I can write code like it's 2025, not 1980. If the biggest features are unimplemented then why upgrade? My concern is the trend continues, and we get cool things like reflection, but it takes 10 years to be implemented properly.
Wow, the list of papers for Modules is large. I can understand why it is taking so long to implement. Also, there needs to be "fingers to do the typing". I assume most of the commercial devs (Google, Apple) just don't think modules are important enough. It looks like Concepts also took a very long time to be fully implemented. Hell, that feature was discussed for 10 years (a dream of Bjarne) before approved into a standard... then maybe 5 years to impl!
Yes, it changed my point of view that it is about time WG21 goes back to the old ways of only standardising existing practice, or at very least proposals without preview implementations shouldn't even get discussed in first place.
The problem is that with the new wind C++ got with C++11, its role in GCC and LLVM, and domains like HPC, HFT, GPGPU, WG21 got up to 300 something members, everyone wanting to leave their name on a C++ standard, many proposing features in PDF form only.
And since in ISO driven languages, what gets into a standard, does so by votes, not technical implementation merit, it is about doing a proper campaign to get the bases to vote for your feature, while being persistent enough to keep the process going. Some features have more than 20 revisions on their proposal.
But this would do nothing to introduce safety-related features, which are still sorely missing after 2+ decades. In light of upcoming regulation to exclude unsafe languages from certain new projects, maybe those features wouldn't be that unimportant after all.
The other side of that coin is that if you required "technical implementation merit", then only people or groups who have strong experience with C++ compilers would be able to propose things.
I'm not saying that the existing situation is ideal and it's certainly not a dichotomy, but you have to consider the detriments as well as the benefits.
You could have a two-stage process. Stage 1 would be the proposal, where you have the discussion on whether the feature is desirable or not, which can then be provisionally accepted. At this point it is not in the standard.
Then you have Stage 2, which would require an actual working implementation, so it can be properly tested and such. Acceptance in Stage 2 would result in the feature being in the standard.
It is worth noting that one of the main reasons why C++ standard evolution is faster nowadays is because the "bare minimum" for consideration of acceptance in the standard is working examples on a fully functioned compiler. This tends to make it a lot easier for other compilers to implement those features as there is at minimum a working reference to compare against (vs older still unimplemented features like modules where nobody really ironed out how to properly implement them until after they were shoehorned into the standard)
Maybe knowing where a language is going will help them implement older features? Also, some things are technically easy once all the conceptual wrinkles are ironed out. There is no reason some of these can't be added before C++20 is 100% supported.
Yeah, I've been very worried about this. C++23 is basically unimplemented as far as I'm concerned. Working on C++26 makes no sense to me. They gotta space it out more than 3 years, if nothing else.
I cannot believe how, after all these years, we don't even have `restrict` in the language, nor uniform function call syntax (i.e. x.foo(y) being interchangeable with foo(x, y) ); but we do get the ultimate bells-and-whistles in the form of reflection and reflection-based code generation; and the half-baked coroutines mechanism.
uniform function call syntax and a `restrict` mechanism have not made it in to the standard after so many years
That is more on the fact that less investment is made in C++ compilers nowadays. Companies are migrating away from C++ and it shows in compiler development.
I write C++, and complain about still not having a portable C++17 implemenation that fully supports parallel STL, not having a full compliant C++20 compiler, embedded compilers kind of still catching up with C++14, and I could rant on.
Are there any embedded compilers left that try to implement their own C++ frontend?
To me it looks like everyone gave up on that and uses the clang/gcc/EDG frontends.
Yes, and even those that have compiler forks aren't on vLatest.
Interesting you mention EDG, as it is now famously know as being the root cause why Visual Studio development experience lags behind cl.exe, pointing out errors that compile just fine, especially if using anything related to C++20 modules.
Apparently since the modules support introduced in VS 2019, there have been other priorities on their roadmap.
reply