|
| 1 | +# Learning to read Arthur Whitney's C to become Smart |
| 2 | + |
| 3 | +- **Category:** Article |
| 4 | +- **Author:** needleful |
| 5 | +- **Date:** 2025-11-03 |
| 6 | +- **Rating:** 5/5 |
| 7 | +- **Link:** [needleful.net](https://needleful.net/blog/2024/01/arthur_whitney.html) |
| 8 | + |
| 9 | +## Abstract |
| 10 | + |
| 11 | +This article explores Arthur Whitney's highly compact C coding style through a detailed analysis of a 50-line interpreter for a simplified K programming language. The author dissects the unconventional use of macros, data types, and implicit arguments, aiming to understand the rationale behind such dense code. The piece concludes by evaluating the strengths and weaknesses of this approach, offering insights into its potential benefits for code comprehension and its challenges for readability and maintainability. |
| 12 | + |
| 13 | +## Summary |
| 14 | + |
| 15 | +The article "Learning to read Arthur Whitney's C to become Smart" by Needleful.net delves into the unique and often perplexing C coding style of Arthur Whitney, known for his work on high-performance programming languages like A, K, and Q, and databases like kdb and Shakti. The author focuses on a publicly available 50-line C interpreter for a simple version of K, which Whitney wrote to demonstrate interpreter basics. |
| 16 | + |
| 17 | +The core of the article is a line-by-line breakdown of the `a.h` header file and the `a.c` source file. The author explains various unconventional C constructs, such as `typedef char*s,c;` where `s` is `char*` and `c` is `char`, and the use of `s Q=(s)128;` where `char*` is treated as an integer for error signaling. Key macros like `_(e...)`, `x(a,e...)`, `$(a,b)`, and `i(n,e)` are demystified, with particular attention paid to GCC's statement expressions `({e;})`. The article also clarifies error handling macros (`Q`, `Qs`, `Qr`, `Qd`, `Qz`), function definition macros (`_s`, `_i`, `f`, `F`), and data type identification (`ax` for "is x an atom?"). |
| 18 | + |
| 19 | +In `a.c`, the author explains functions for printing (`w`, `W`, `wi`), error reporting (`err`), memory allocation (`m`), and various array operations like `not`, `sub`, `At`, `_A`, `ind`, `Ind`, `cat`, `rev`, `cnt`, `Tak`, `Sub`, and `Mtn`. A significant portion is dedicated to unraveling the `G(f,o)` macro, which defines binary operations that work uniformly on atoms and vectors, showcasing complex nested ternary operators. The article also details the `v(e)` macro for operator lookup, the `U` and `V` arrays for variables and operators, and the `n(x)` function for parsing numeric and variable characters. The intricate, recursive evaluation function `e` is broken down, revealing the right-to-left, no-operator-precedence execution typical of APL-like languages. Finally, the `main` function, which reads user input and prints evaluated results, is explained. |
| 20 | + |
| 21 | +The author concludes by reflecting on the experience, highlighting both the "good ideas" and "bad ideas" of Whitney's style. Good ideas include well-considered, composable primitives and the resulting code compactness, which reduces scrolling. Bad ideas encompass non-semantic types (e.g., `char*` as an integer), excessive code golf (e.g., ASCII codes instead of character literals, obscure range checks), and non-standard syntax (GCC extensions). The author is ambivalent about implicit arguments and short names, acknowledging their role in density but also their impact on initial readability. The key takeaway for the author is that this style is best suited for "done" code, implying a need for thorough problem understanding before implementation, contrasting with the author's own iterative, refactoring-heavy approach. |
| 22 | + |
| 23 | +## Strong Sides |
| 24 | + |
| 25 | +* **Well-considered Primitives:** The coding style utilizes composable and useful macros that effectively reduce repetition, making common operations like iteration easier to decipher. This approach is akin to using higher-order functions in other languages. |
| 26 | +* **Code Compactness:** The dense nature of the code, achieved through macros and short names, allows the entire logic to fit on a single screen, potentially reducing the need for constant scrolling in large codebases. |
| 27 | +* **Reduced Bugs (Potentially):** By working with small, well-defined building blocks, the method might lead to fewer bugs once the style is mastered, as the logic for each component is highly focused. |
| 28 | +* **Emphasis on Pre-computation/Design:** The style encourages a deep understanding of the problem before writing code, leading to a more "finalized" and mathematically precise implementation rather than iterative refactoring. |
| 29 | + |
| 30 | +## Weak Sides |
| 31 | + |
| 32 | +* **Non-semantic Types:** The unconventional use of types, such as `char*` being treated as an integer, can be highly confusing and non-intuitive, requiring external documentation or prior knowledge to understand. |
| 33 | +* **Code Golfing:** Excessive brevity, like using ASCII codes instead of character literals or obscure range checks (e.g., `10u>x-48`), significantly hinders readability for minor gains in line count. |
| 34 | +* **Non-standard Syntax:** Reliance on GCC-specific extensions (e.g., statement expressions, `a ?: b` ternary operator) makes the code less portable and can lead to compilation issues with other compilers. |
| 35 | +* **Implicit Arguments:** While contributing to compactness, the pervasive use of implicit variables (`x`, `a`, `i`) makes the code harder to parse at first glance, requiring a significant adjustment period. |
| 36 | +* **Short Names without Context:** While short names can be efficient, they lack semantic signal, forcing readers to deduce meaning from context rather than explicit naming, especially for complex operations. |
| 37 | +* **Nested Ternary Operators:** The deep nesting of ternary operators, particularly in macros like `G`, can be extremely difficult to follow without extensive mental chunking or reformatting. |
| 38 | +* **Lack of Error Handling/Robustness:** The interpreter assumes `malloc` will not return pointers below 256 and reserves `128` for invalid results, indicating potential limitations and lack of robust error handling for a production system. |
| 39 | +* **Compiler Warnings:** Compiling the code without suppressing warnings generates numerous alerts, which can obscure genuinely useful compiler feedback. |
| 40 | + |
| 41 | +## Review of the Article |
| 42 | + |
| 43 | +The article provides an exceptionally thorough and engaging analysis of Arthur Whitney's C coding style. Its primary strength lies in the meticulous, line-by-line deconstruction of the interpreter code, which effectively demystifies many of the initially "incomprehensible" constructs. The author's personal journey of understanding, including moments of confusion and eventual clarity, makes the explanation relatable and humanizes a topic that could otherwise be dry and overly technical. The inclusion of specific code snippets and their detailed explanations, along with references to annotated versions when the author was stuck, is highly beneficial for readers attempting to follow along. |
| 44 | + |
| 45 | +The article is well-structured, moving logically from an introduction to Whitney's work, through the code analysis, and finally to a thoughtful conclusion. The "Good ideas," "Bad ideas," and "Ambivalent ideas" sections offer a balanced and insightful critique of the coding style, providing concrete examples for each point. The author's personal reflections on how this exercise impacts their own coding philosophy—emphasizing the importance of pre-computation and a clear mental model before coding—add significant value and make the article more than just a technical breakdown. |
| 46 | + |
| 47 | +One minor area for improvement could be a slightly more explicit initial overview of the K language's core paradigms (e.g., array-oriented, tacit programming) before diving into the C implementation, as this context would further illuminate *why* Whitney codes the way he does. However, the article does touch upon these influences later. |
| 48 | + |
| 49 | +Overall, this is an excellent piece for anyone interested in low-level C programming, code optimization, or the unique styles of influential programmers. It serves as both an educational resource for understanding complex C macros and a thought-provoking essay on coding philosophy and readability. |
0 commit comments