4,493
edits
Readability: Difference between revisions
Jump to navigation
Jump to search
→Honeywell
No edit summary |
|||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
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,<ref>Abrams, Phil. ''Program Writing, Rewriting and Style''. APL Conference 73. Canadian Printco Limited. 1973.</ref> 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!''<ref>Perlis, Alan. [https://www.jsoftware.com/papers/perlis78.htm Almost Perfect Artifacts Improve only in Small Ways: APL is more French than English]. [[APL '78]].</ref> [[Code golf]] often results in pornographic code. | 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,<ref>Abrams, Phil. ''Program Writing, Rewriting and Style''. APL Conference 73. Canadian Printco Limited. 1973.</ref> 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!''<ref>Perlis, Alan. [https://www.jsoftware.com/papers/perlis78.htm Almost Perfect Artifacts Improve only in Small Ways: APL is more French than English]. [[APL '78]].</ref> | ||
== 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 [[dfn]]s, it became possible to define a full function or operator on a single line. Since APL [[comment]]s begin at the comment symbol (<source lang=apl inline>⍝</source>) 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 [[wikipedia:debugger|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.<ref>[[John Scholes|Scholes, John]]. [https://dfns.dyalog.com/n_kk.htm Kind Koloring of d-fnop named ⍵.] Dfns workspace. [[Dyalog Ltd.]]</ref> | |||
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#Publications|Adám Brudzewsky's style guide]] is an example of such a style guide. | |||
== Examples == | == Examples == | ||
=== Gilman & Rose === | === Gilman & Rose === | ||
In [[Books#APL_.E2.80.95_An_Interactive_Approach|APL ― An Interactive Approach]], the authors describe the following code, which computes the correlation coefficient, as “almost pornographic”: | In [[Books#APL_.E2.80.95_An_Interactive_Approach|APL ― An Interactive Approach]], the authors describe the following code, which computes the correlation coefficient, as “almost pornographic”: | ||
:<source lang= | :<source lang=apl inline>r←(+/x×y)÷((+/(x←x-(+/x)÷⍴x)*2)×+/(y←y-(+/y)÷⍴y)*2)×.5</source> | ||
By splitting the expression intro even a moderate number of pieces, a symmetry is revealed: | By splitting the expression intro even a moderate number of pieces, a symmetry is revealed: | ||
<source lang= | <source lang=apl>yVar←+/(y-(+/y)÷⍴y)*2 | ||
xVar←+/(x-(+/x)÷⍴x)*2 | xVar←+/(x-(+/x)÷⍴x)*2 | ||
r←(+/x×y)÷(xVar×yVar)×0.5</source> | r←(+/x×y)÷(xVar×yVar)×0.5</source> | ||
| Line 63: | Line 73: | ||
<source lang=apl> | <source lang=apl> | ||
a←4 | a←4 | ||
( | (a←3)×a | ||
</source> | </source> | ||
where it is undefined whether the initial value for <source lang=apl inline>a</source> 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. | where it is undefined whether the initial value for <source lang=apl inline>a</source> 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. | ||
| Line 75: | Line 85: | ||
The Multics APL manual goes on to use the terms ''monstrosity'' and ''eyesore'' for code published in an APL newsletter, such as | The Multics APL manual goes on to use the terms ''monstrosity'' and ''eyesore'' for code published in an APL newsletter, such as | ||
:<source lang= | :<source lang=apl inline>Z[B+(C∧X∊D)/⍳⍴X;]+(24p' Y9 X9 ')[(C←(-≠\''''=X)∧A≤⍴D)/A←(D←'⍵⍺')⍳X;]</source> | ||
The manual suggests that this code should be split into the following expressions: | The manual suggests that this code should be split into the following expressions: | ||
<source lang=apl> | <source lang=apl> | ||
| Line 84: | Line 94: | ||
Z[B;]←(24p' Y9 X9 ')[C/A;] | Z[B;]←(24p' Y9 X9 ')[C/A;] | ||
</source> | </source> | ||
== See also == | == See also == | ||
* [[Semantic density]] | * [[Semantic density]] | ||
| Line 89: | Line 100: | ||
== References == | == References == | ||
<references/> | <references/> | ||
{{APL syntax}} | {{APL syntax}}[[Category:Culture]] | ||