Readability

Maintaining readability of APL can take a special effort. It is easy to write very dense code, and the mathematical look of APL can encourage usage of single-letter names. Since Phil Abrams used the term at the APL '73 conference, APLers have traditionally used pornography to describe code that is hard to read, or uses unusual constructs. Alan Perlis countered that But as we all know, being people of the world, pornography thrives!

Causes and mitigation
Code golf often results in pornographic code, as does the practice of cramming a whole algorithm into a single line, forming a one-liner. When computer memory was very limited, such code golf was often a necessary evil.

With the advent of dfns, it became possible to define a full function or operator on a single line. Since APL comments begin at the comment symbol and continue until the end of the line, it is impossible to comment a one-liner dfn except outside the source. This, coupled with the inability of a debugger to meaningfully trace through a one-liner (unless it is capable of primitive-by-primitive tracing), constitute hardships for a human reader that attempts to read such code.

APL containing user defined names is generally not statically parseable, as the name class, and thus the syntactic role, of such names isn't known until runtime.

Much can be done to improve readability of code, and of APL in particular. Breaking code up into meaningful statements, avoiding one-liners, using descriptive names, and supplying plentiful comments are a good start. Adherence to a well-defined style guide can also help. Adám Brudzewsky's style guide is an example of such a style guide.

Gilman & Rose
In APL ― An Interactive Approach, the authors describe the following code, which computes the correlation coefficient, as “almost pornographic”:

By splitting the expression intro even a moderate number of pieces, a symmetry is revealed: This also avoids reusing variable names, and thus ensures that the code can be rerun from any point. The chosen additional variable names are still short, but quite indicative of what they signify (variance). Finally, the  is expanded to   which helps to clarify that this is a decimal number and not an inner product.

A more modern approach breaks out the symmetry into a utility function train, and uses leading axis theory combined with operators and reordering of terms to avoid parentheses (which would otherwise require a mental stack to understand). Finally, the correlation coefficient is defined as a stand-alone function, using inner product to combine summation with multiplication Note that  is an idiom (common phrase) and is read as average by even moderately experienced APL programmers.

IBM
The idiom list included with APL2 includes the following entry:
 * {| style=width:100%

This was once a common technique before, even though it is prone to fail in where the value to the left of  isn't a vector, for example in the following example where   becomes a 1-element vector instead of the intended scalar: With the addition of Left to the language, this type of hack became became entirely obsolete:
 * }
 * }

The primitive leaves its left argument unmodified: The Diamond statement separator provides an alternative means of inlining multiple statements:

Note that in all the above,  is assigned first.

Morten Kromberg
Morten Kromberg asked one of his colleagues to “Please avoid this kind of pornography:” Avoiding the unusual modified assignment (using the 2-train  as modifying function) helps: Finally, splitting the 2-train apart makes it even clearer: A new namespace, with the original value of  as name, is created inside   and the character representation   is returned from   to   which evaluates the name to a reference, that in turn replaces the previous value of. Note that  returns fully qualified namespace path to the newly created namespace, and thus it doesn't matter in which namespace   is called.

Honeywell
Honeywell used a more specific definition:
 * In APL, pornography is defined informally as the dependence upon undefined evaluation order for the successful or correct evaluation of an APL statement.

This refers to things like where it is undefined whether the initial value for  is used at all in the second line, yielding 12, or whether the second assignment is done before times gets its right argument, and thus the result is 9.

Similarly, in the evaluation order of the statements in the bracket indexing is undefined. If  is evaluated before   then the result is 20, otherwise it is 10.

The Multics APL manual goes on to use the terms monstrosity and eyesore for code published in an APL newsletter, such as

The manual suggests that this code should be split into the following expressions: