Floating-point numbers are NOT real numbers!

In every introduction to programming, one has to see the author spout this nonsense. Never mind that a format that represents every real number through a finite bit pattern is a simple mathematical impossibility^[1] and doing it in a bit pattern of fixed length even more so; never mind that this supposedly-white lie breeds nothing but confusion when the newly-made programmer tries to do ``real'' arithmetic only to encounter seemingly random rounding errors and concludes that floating-point arithmetic is black magic that corrupts your digital fluids; never mind the staggering amount of subtly wrong programs that deal with fixed-point quantities like money through floating-point arithmetic when there was never any reason to have rounding errors enter the problem or solution.

Floating-point arithmetic is not difficult. It works like you'd do arithmetic on paper with a fixed amount of digits, except for the fact that your digits are binary and so the amount of rationals with finitely many digits is a bit smaller. There exist good texts on floating-point arithmetic, understandable even for the kind of mental midget that studies CS to write DISRUPTIVE ENTERPRISE NANOSERVICES nowadays. [2] was written in 1991 -- what's your excuse? If you want to understand the rounding behaviour better, every decent book on numerical analysis contains a section on it and books like Wilkinson's Rounding Errors in Algebraic Processes (1961) go even further into detail. Not that you need much beyond the trivially derived (even if coarse) bounds in anything that isn't a serious numerical problem; and if it is one, why the fuck did you not learn numerical analysis before tackling it?

Where does this fetishism for ignorance in programming stem from? Nowhere else have I seen a supposedly technical field that happily ignores its own history, takes pride in using something without having read as much as the goddamn manual (let alone a book) and outright teaches this ignorance.

^{[1] Yes, yes, the computable real numbers are by definition representable and a triple Shalom! to Cantor and the powerset axiom. While we wait for the system that represents every number as an algorithm producing its digits, let's keep things classical.
[2] https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf}

>>5

How many languages cannot react to OOM conditions, e.g. to allow you to drop caches? As far as I know not even Common Lisp can do that portably, though I might be wrong there. OOM handling in general is a place where the ``state of the art'' is abominably primitive even though it is a fundamental problem.

PL/I handles this by raising the STORAGE condition (or AREA condition if allocating in an area). Each procedure call or block activation can be associated with a handler for each condition. Handlers are enabled by the ON statement, which can be controlled conditionally because it's a statement like I/O and assignment. After the condition is handled by an ON STORAGE statement, and if the handlers return normally, the allocation is retried. If there's still not enough memory, the condition is raised again. PL/I has lexical scope and does not unwind the stack so these handlers can change variables in their scope, like freeing memory and setting variables to tell what has been freed. Eventually, if there are no more handlers and still insufficient memory, there is some system-specific action, like printing a stack trace or starting a debugger. The stack is still not unwound, so the debugger can fix a problem and continue.