This article makes it sound more complicated than it is, collecting all those edge cases. Many of them can be simply ignored, as in being no-op. Which is also what most cheap calculators do...
Sometimes you just have to put your foot down and just say "No, that is not how you use this tool".
> Shit. I was just about to launch into an explanation of our code review procedures. Every week we sit around a table and carefully and dispassionately analyse and constructively criticise each others code. And it works. We sit there and listen and take it all in. It works really well and team morale is excellent. One day we're even planning to do one when we're sober.
You can even go fancy with floating point if you want (Probably elims the $0.30 MCUs). Tiny, cheap, and you can model it using appropriately expressive data structures (like rust enums) that handle the edge cases at the CPU level.
I don't mean to dismiss your comment; it's important. I think this article is skirting a gray area of which constraints are applied. Then the conclusion is altered. Is it saying making a 4-function calculator is complicated!, or is it saying making a 4-function calculator is complicated if you add a number of specific restrictions and requirements (No modern CPU code, exact behavior replication to all combinations of user input etc). The latter is less interesting.