Since this flurry of APL/J/K/A+/Q articles started, I've been wondering about the relationship between APLs and literate programming.

They say that APL was developed to mimic mathematical notation, and I see the resemblance. But real works of mathematics consist of one or two lines of expressions separated by sentences and paragraphs explaining the goal of those expressions.

So far in K "advertising" I only see the expressions and not the explanations. The explanation is there, but it's not a comment in the codebase; it's in a blog post that explains it. The code has many lines of expressions on top of each other, and nobody writes math that way.

I feel like I'm missing something, basically. It's clear how to write K, but what are the best practices for making a large codebase readable? I shouldn't have to invent that myself, right?

Assuming you write your code for a certain domain, I think most of your colleagues could follow along after learning a little k.

I wrote a toy simulator for the domain I work in using something like 6 lines of APL code and sent it to someone good with APL. They replied back to the email pretty quickly with some tips on how to improve it and could generally get the gist of what I was trying to do while knowing nothing of the problem domain. It was really an interesting experience. I think with zero doc, a colleague of mine would immediately understand what I was doing after going through a short APL tutorial. It isn't magic, but not nearly as cryptic as people make it out to be.

Edit: people do comment their APL code. I think a million loc project would be pretty difficult in APL, but the beauty is that you should be able to do some pretty powerful work in a few pages I would imagine.

I think you're right. Aaron Hsu's work in APL is inspiring and awesome. The source code to his data parallel compiler hosted on the GPU is 17 lines of APL! Read the abstract to his paper here:

https://scholarworks.iu.edu/dspace/handle/2022/24749

The source code to his data parallel compiler hosted on the GPU is 17 lines of APL!

The co-dfns source I've seen[1] is much longer. Do you know if there's a write-up somewhere of the differences between that and Appendix B from the dissertation?

1: https://github.com/Co-dfns/Co-dfns