Recently an article regarding the ShellShock vulnerability asserted "The average programmers writes 10x more code than they read. The only people where that equation is reversed are professional code auditors." [1]
Granted, any such claim should be taken with a grain of salt. I haven't seen much evidence one way or the other how much code the average programmer reads. And I suspect the issue is more complicated, like most programmers all reading similar toy-sized example code. But, given the conventional unsubstantiated assertion is the opposite (read 10x as much as write), this was jarring enough to get me thinking:
Perhaps "reading code" really isn't the way we should comprehend code.
Reading code has a lot of disadvantages. First, code is incredibly dry. If I'm going to curl up with something to read, I'd rather grab a Dresden book by Jim Butcher (← shameless plug ;). Second, 'reading' code is really asking us to 'simulate code in your head', which requires a great deal of codebase-specific knowledge and attention to detail.
Of course, code maintenance is still important.
If we abandon reading of code, other tools and techniques for comprehension and maintenance would need to step up their game. Possibilities include automatic debugging, property testing, automatic property discovery, live programming, history and animation, typing/linting, easy sandboxing and playgrounds, zero button testing. It would help, also, if our bedrock [2] languages allow us to rapidly isolate errors via composition and locality principles (via capability security, effect typing, etc.).
Anyhow, back on the topic of APL...
It seems to me that 'write only code' would be much less an aspersion against a programming language (or program) if we weren't expected to read other people's code as a primary mechanism for comprehending and maintaining it. Further, avoiding the burdens and overheads of 'readable code' might be the better long term direction, and result in greater accessibility of programs to users.