However, I found the programs being discussed in the J discussion lists completely impenetrable.
I would argue that (a big) part of the issue is that proponents often overstate the readability of such code. My usual experience from the J mailing list is that people "read" code by looking at the prose description of what it does, puzzling through how they would do that themselves, and then looking for common structure between the original code and their own reimplementation. It's a good learning experience as far as solving that particular problem is concerned (as there's often more than one way to do it), though it definitely runs counter to the meme that comments and meaningful names are superfluous. The other usual excuse that "the alphabet just isn't the one you're familiar with" isn't really true of mailing list regulars.
That's one of the major reasons I think handwriting J is more interesting and understandable than typing it. You can more clearly mark which pieces are conjunctions and what they operate on, you can present the explicit expansion tree as a reference, etc.
I thought the punchline was that he was going to use image-recognition to read the hand-drawn J programs.
If you want that kind of overkill, how about using interprocedural data-flow analysis to try to parse APL?
I actually thought this was going in a different direction:
http://www.jsoftware.com/papers/tot.htm
This is Iverson discussing APL (predecessor language of J) and its utility/advantages as a notational tool. In particular, something that I find interesting to see here since I just reread (most of) it, is a mention of ad hoc notations introduced as needed by the user. What today we would call domain specific languages.