It's a reach, but the Fourier transformation of a Schwarz (rapidly decaying) function is also a Schwarz function. Compact support is a strictly stronger condition than Schwarz (the function must eventually decay to 0) but doesn't have this nice property with respect to Fourier transforms, i.e. the FT of a compactly supported function is Schwarz but not necessarily compactly supported
What you're saying is "descriptive method names aren't a substitute for knowing how the code works." That's once again just a basic fact. It's not "hiding," it's "organization." Organization makes it easier to take a high level view of the code, it doesn't preclude you from digging in at a lower level.
No, your argument is equally applicable to all methods. The idea that a method hides implementation details is not a real criticism, it's just a basic fact.
No, not "almost every modern developer thinks inheritance is just bad." They recognize that "prefer composition over inheritance" has merit. That doesn't mean inheritance is itself a bad thing, just a situational one. The .NET and Java ecosystems are built out of largely object-oriented designs.
I dunno, but the last season takes a hard left turn with one major character leaving the pd for ethical reasons and the others struggling with their part in the institution. It was definitely informed by current events.
I worked with Progress via an ERP that had been untouched and unsupported for almost 20 years. Damn easy to break stuff, more footguns than SQL somehow
Just explaining that the limitations of Gödel's theorems are mostly formal in nature. If they are applicable, the more likely case of incompleteness (as opposed to inconsistency) is not really a problem.
This should be done with font ligatures, not replacing character combinations with other characters that can't be typed normally