Learning to read Arthur Whitney's C to become smart (2024)

Reactions to Whitney’s C Style

• Many describe the code as “obfuscated”, “psychotic”, or IOCCC‑like; several say even machine‑obfuscated C they’ve seen was clearer.
• Others find it beautiful, dense, and “satisfying” once understood, praising how much functionality fits in one page.
• A recurring joke: reading it causes “madness” or “mental illness”, and will make you “crazy and unemployable”, not smart.

APL / J / K Influence and How to Read It

• Some argue the right way to understand this C is to first learn APL/J/K: Whitney is writing C as if it were an array language, with single‑character names, ultra‑dense one‑line functions, and a tight set of primitives.
• Others counter that the C itself isn’t especially “APL‑like”: APL’s array primitives, immutability, and lack of macros don’t map directly to this style; it’s more Whitney‑specific.
• There’s disagreement whether the article actually claims the C is APL‑inspired or just written by “the APL guy”.
• Several note that after learning APL/J, Whitney’s interpreters become surprisingly readable and expressive, communicating design trade‑offs clearly.

Macros, Preprocessor Tricks, and DSLs

• Core macros like _(e...), x(a,e...), $(a,b), i(n,e) are seen by some as elegant tools to build a tiny DSL on top of C and climb an “abstraction ladder” quickly.
• Others call them “war crimes”: ad‑hoc, unreadable, sometimes unsafe (e.g. missing braces in $(a,b)), and dependent on non‑standard extensions like GCC’s a ?: b.
• Broader debate: C macros can define useful DSLs (compared to SystemC, JSON‑in‑C configs, etc.) versus the view that they’re almost always a maintenance hazard.
• One thread explores using preprocessors to selectively expand macros to “de‑DSL” a codebase.

Readability, Maintainability, and “Best Practices”

• Strong camp: this is exactly how you should not write C—most teams need descriptive names, comments, and conventional control structures to debug and onboard people.
• Counterpoint: “best practices” are really “mediocre practices” optimized for large, high‑turnover teams; for a single expert maintaining tiny interpreters over decades, extreme terseness can be rational.
• Several emphasize that code is communication; deviating too far from familiar idioms is like inventing your own grammar and expecting others to cope.

Learning Value

• Some readers find the blog post an excellent guided tour: a rare chance to see a compact, complete interpreter and think about density, abstraction, and DSL design.
• Others argue that studying this style is interesting but not a path to being “smarter” at everyday C; better to read good conventional code in many styles.