Hacker News Reader

Comment by electroly | Hacker News Reader

The way to understand Arthur Whitney's C code is to first learn APL (or, more appropriately, one of his languages in the family). If you skip that part, it'll just look like a weirdo C convention, when really he's trying to write C as if it were APL. The most obvious of the typographic stylings--the lack of spaces, single-character names, and functions on a single line--are how he writes APL too. This is perhaps like being a Pascal programmer coming to C and indignantly starting with "#define begin {" and so forth, except that atw is not a mere mortal like us.

View on HN

> The way to understand Arthur Whitney's C code is to first learn APL

This is the main insight in my breakdown of the J Incunabulum:

https://blog.wilsonb.com/posts/2025-06-06-readable-code-is-u...

When I first encountered it years ago, the thing was impenetrable, but after learning APL to a high level, it now reads like a simple, direct expression of intent. The code even clearly communicates design tradeoffs and the intended focus of experimentation. Or more on the nose, to me the code ends up feeling primarily like extremely readable communication of ideas between like-minded humans. This is a very rare thing in software development in my experience.

IMHO, ideas around "readable code" and "good practices" in software development these days optimize for large, high-turnover teams working on large codebases. Statistically speaking, network effects mean that these are the codebasese and developer experiences we are most likely to hear about. However, as an industry, I think we are relatively blind to alternatives. We don't have sufficient shared language and cognitive tooling to understand how to optimize software dev for small, expert teams.

Thanks for that breakdown, that does make it a lot more understandable.

> DO defines our basic loop operation, so iterations will probably all naïvely be O(1);

Shouldn't that be "naïvely be O(n)"?

It looks like a weirdo C convention to APLers too though. Whitney writes K that way, but single-line functions in particular aren't used a lot in production APL, and weren't even possible before dfns were introduced (the classic "tradfn" always starts with a header line). All the stuff like macros with implicit variable names, type punning, and ternary operators just doesn't exist in APL. And what APL's actually about, arithmetic and other primives that act on whole immutable arrays, is not part of the style at all!

"the typographic stylings ... are how he writes" is what I said, isn't it? :) Well said.

>This is perhaps like being a Pascal programmer coming to C and indignantly starting with "#define begin {" and so forth

Ah, like Stephen Bourne

My first thought was "oh, this just looks like a functional language" but my next thought was "with the added benefit of relying on the horrors of the C preprocessor."

Would learning J work instead?

It’s probably more accessible than APL since its symbols can be found on conventional keyboards.

Every time I read about APL, I'm reminded of Lev Grossman's "The Magicians" — I'm always imagining some keyboard with just a little bit more than two dimensions; and, with sufficient capabilities, I could stretch to hit the meta-keys that let me type APL directly on my modified split MTGAP keyboard.

We know, the beginning of the article tells us his C code is APL-inspired. So many comments that just summarize the article on a surface level.

Yes, but... even if you know that it is APL inspired, that does not change the fact that this is not how you want to write C.

The C pre-processor is probably one of the most abused pieces of the C toolchain and I've had to clean up more than once after a 'clever' programmer left the premises and their colleagues had no idea of what they were looking at. Just don't. Keep it simple, and comment your intent, not what the code does. Use descriptive names. Avoid globally scoped data and functions with side effects.

That doesn't look smart and it won't make you look smart, but it is smart because the stuff you build will be reliable, predictable and maintainable.

Layman question: say you have a C codebase with a bunch of preprocessor macros and you want to get rid of a particular one that's too clever, and assume no other macros depend on it.

Is it possible to command the preprocessor to take the source files as input and print them out with that one particular macro expanded and no other changes?

Intuitively, it sounds like it should be possible, and then you'd end up with a code base with a bunch of repetition but one fewer too-clever abstraction - and refactoring to deal with repetition (if necessary!) is a far more approachable and well-understood problem.

(Kind of like how some fancy compiles-to-javascript languages have a literal 'mytool --escape' command that will turn the entire code base into a plain, non-minified javascript in case you ever want to stop using them.)

That's a great question.

I found this on SO:

https://stackoverflow.com/questions/59553295/selective-macro...

Maybe that would work for your use case?

What I like about your question is that I always assumed the answer was a hard 'no' but that appears not to be the case.

It was a theoretical question. It's not the first time I hear the complaint '$previous_dev left a bunch of unmaintainable macro tricks in a C codebase' and I thought, since those macros get expanded as part of the compilation process, surely it should be possible to intercept and capture the expanded version?

Even if a whitelist is not available (the SO question involves a particular C++ preprocessor and may not apply to others), a hacky approach might be to comment out all the #defines in the codebase, uncomment the ones you want to get rid of, and then run the full preprocessor task on it. Ugly but probably doable for a one-time refactoring.

The beginning of the article talks about not learning APL--specifically mentions that he's not here to talk about APL--and proceeds into a wide-eyed dissection of the C without mentioning APL syntax again. It also doesn't, literally, say that the C is like APL; it says Arthur is an APL guy who writes weird C code. Another comment disagrees that this is APL style at all--which is it?? I think you could have given me more credit than this. I read the article and participated as best I could. I'm always happy to bump APL related articles so they get more visibility.

It's irrelevant that someone doesn't think the code is APL-inspired. Their disagreement is as much with the article as your comment. I felt like what is written in the article already implied what I then read in your comment. Credit where due, the disagreement with the article probably would've not been posted if the implications in that part hadn't been re-stated plainly. Comments like these can be useful as pointers to specific aspects of an article, where conversations can be organized under, now that I think about it.

Dunno why electroly is dragging me into this but I believe you've misread the article. When it says "His languages take significantly after APL" it means the languages themselves and not their implementations.

The article: "Let's make sense of the C code by the APL guy"

Do you think the article meant to say it was more likely that the code wasn't inspired by APL?

I think the article expresses no position. Most source code for array languages is not, in fact, inspired by APL. I encourage you to check a few random entries at [0]; Kap and April are some particularly wordy implementations, and even A+ mostly consists of code by programmers other than Whitney, with a variety of styles.

I do agree that Whitney was inspired to some extent by APL conventions (not exclusively; he was quite a Lisp fan and that's the source of his indentation style when he writes multi-line functions, e.g. in [1]). The original comment was not just a summary of this claim but more like an elaboration, and began with the much stronger statement "The way to understand Arthur Whitney's C code is to first learn APL", which I moderately disagree with.

[0] https://aplwiki.com/wiki/List_of_open-source_array_languages

[1] https://code.jsoftware.com/wiki/Essays/Incunabulum

I unfortunately glossed over the part of the original comment that gives it substance: "The most obvious of the typographic stylings--the lack of spaces, single-character names, and functions on a single line--are how he writes APL too."

That's backing for a claim.

Also, I haven't once written APL. I think this might've been borderline trolling, just because of how little investment I have in the topic in reality. Sorry.

Reply on news.ycombinator.com