The Weird Parts | Understanding

Write code that explicitly tests weird behaviors. Derive mathematical paradoxes step by step. Try to construct sentences that break your native language’s grammar rules. Weird parts become familiar only through exposure. But not passive exposure—active experimentation. Change one variable, see what happens. Ask “what if” questions.

Why do such parts exist? Often, because formal systems grow organically. Programming languages evolve from practical needs, accruing edge cases and legacy behaviors. Mathematics expands by generalization, sometimes producing results that contradict earlier intuitions (e.g., the Banach-Tarski paradox). Human cognition itself is a patchwork of evolutionary shortcuts, leading to systematic biases. The weird parts are not bugs in the universe—they are features of systems that were never designed from scratch with perfect foresight. Perhaps no field offers a richer collection of weird parts than software engineering. Consider JavaScript’s type coercion: [] + [] evaluates to an empty string, [] + {} becomes "[object Object]" , but {} + [] is 0 . The explanation involves the language’s implicit type conversion rules, the distinction between statement and expression contexts, and the + operator’s overloaded behavior. At first glance, this seems arbitrary. But after studying the specification—how the ToPrimitive abstract operation works, how valueOf and toString are called—the weirdness becomes understandable. It is still surprising, but no longer mysterious. understanding the weird parts

Similarly, Python’s default mutable arguments are a classic weird part: def append_to(element, target=[]): target.append(element); return target will share the same list across multiple calls if not passed explicitly. This violates the expectation that default arguments are recreated each time. The underlying reason is that default arguments are evaluated at function definition time, not at call time. Understanding this requires shifting from an intuitive “fresh copy each time” model to the actual model: default arguments are stored as attributes of the function object. Write code that explicitly tests weird behaviors