There's a whole series of (long) comments by arcfide [0] about APL, and code in general, in the "Smaller Code, Better Code" thread [1] that I thought were great.

In particular this one [2].

"I'm pushing the other direction. If you can see your entire compiler at one go on a standard computer screen, what sort of possibilities does that open up? You can start thinking at the macro level, and simply avoid a whole host of problems because they are obviously wrong at that level. When you aren't afraid to delete you entire compiler and start from scratch? What sort of possibilities does that open up to you?"

[0] https://news.ycombinator.com/user?id=arcfide

[1] https://news.ycombinator.com/item?id=13565743

[2] https://news.ycombinator.com/item?id=13571160

IMHO if you look at the history of how computers were programmed, then you will see that functions/subroutines/procedures/callable blocks/etc., as well as other abstractions, were basically invented to serve a very obvious and utilitarian purpose: to reduce duplication of code; and anything beyond this is dubious.

I find "straight-line" code, perhaps in one long function, with comments to provide commentary and "navigation", far easier to read than the dozens-of-tiny-and-verbosely-named-functions style too. The "readability" argument is commonly used, but it's focusing on the wrong thing: a single-line function is certainly going to be easier to understand than a 512-line function, but understanding a single-line function does not make it any easier to understand the system/algorithm/etc. as a whole. The latter is extremely important, because not knowing "the big picture" can lead to very bad decisions overall; I've seen many cases where bugs or accidental and severe inefficiencies (e.g. unnecessary allocations, high-polynomial complexity, multiply duplicate accesses to data, etc.) were created because the author of the code only focused on a tiny piece and neglected to consider its application in the whole.

There are some very insightful posts by an APL(!) programmer here, discussing the topic of complexity overall vs. complexity in parts:

https://news.ycombinator.com/item?id=13565743

https://news.ycombinator.com/item?id=13797797

I suspect part of the motivation for producing "microfunctions" may have come from a misunderstanding of the "decompose the problem" principle --- which is intended to mean that you, as a programmer, decompose the problem into simpler steps --- but not that each step necessarily warrants a function.

The same problem and principles apply to other levels of organisation: classes, structures, files. etc. --- they are intended to reduce duplication and simplify code, but will have the opposite effect if used to excess.

His APL to GPU compiler is less than 1000 loc in it's entirety and the "comments" are the 400 page accompanying master's thesis.

There are a few HN discussions u/arcfide and several YouTube presentations at functional programming conferences. Neat stuff!

https://news.ycombinator.com/item?id=13565743

https://www.sacrideo.us/smaller-code-better-code/