jffhn

>Want to store 90 degrees in radians? No matter how many bits you use, it will never be exact.

That can be seen as a feature: cos(angRad) will never return zero, avoiding edge cases, and same with sin(angRad) if argument is not zero.

>Creating software that isn't outright wasteful in terms of performance isn't even hard, it's just a matter of not doing ridiculously dumb things.

Non-tautological rephrasing: When optimizing code, first actually just de-slowify it, and that should most often be plenty enough.

Also, the four fallacies of local computing:

- The CPU is infinitely fast.

- RAM is infinite.

- CPU caches don't exist.

- Cache lines don't exist.

It cannot be just a product of the body, else it could not have effect on the body and our tongues could not be moving speaking about it.

We don't experience the sun going up and down, we experience its direction changing relative to the horizontal plane, and it is not an illusion: it matches planetary motion. The mistake arises when interpreting the raw experience. Sensations don't lie. Another example: Metal feels colder than plastic, but the sensation is right again: you are loosing more heat when touching metal.

Bounded collections still allow for useless reachings of their bounds, and corresponding memory and CPU wastes (and possibly functional/domain issues).

The main reason I saw around me for memory leaks in GC'ed languages, is devs only thinking about the 'add' part, not the 'when-to-remove' part. I always think of both and the only leaks I got were from slowdowns causing events to pile up in scheduler queues (deliberately not bounded).

Before, not after: when the code makes it hard to implement a new feature (the definition of technical debt: code that is properly designed but only for previous features), first refactor the code to make the feature easy to implement, then implement the feature.

>Do people really argue about variable names?

Of course they do. A program's code is mostly a graph of names; they can be cornerstones of its clarity, or sources of confusion and bugs.

The first thing I do when debugging is ensuring proper names, sometimes that's enough to make the bug obvious.