4,500
edits
Miraheze>Marshall mNo edit summary |
No edit summary |
||
(3 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
Semantic density is a ''metric'' of the readability of a program by a non-programming domain expert. | |||
Programs work with ''representations'' of some domain. Every program must thus be read in two ways: | Programs work with ''representations'' of some domain. Every program must thus be read in two ways: | ||
Line 8: | Line 8: | ||
The programmer must understand enough of the first to have the computer animate the representational scheme – adequately to the needs of the domain expert. The domain expert can participate in this process most closely when able to follow the domain logic in the program. | The programmer must understand enough of the first to have the computer animate the representational scheme – adequately to the needs of the domain expert. The domain expert can participate in this process most closely when able to follow the domain logic in the program. | ||
This is possible when a sufficiently high proportion of the tokens (eg names of | This is possible when a sufficiently high proportion of the tokens (eg names of [[variable]]s or [[function]]s) are drawn from the vocabulary of the reader. (Writers of natural languages, under a general injunction to write with their readers in mind, will find nothing surprising in this.) | ||
Leaving aside any familiarity with programming, the minimum threshold appears to vary little between readers, and is in all cases high. Even a low proportion of ‘foreign’ terms degrades readability. | Leaving aside any familiarity with programming, the minimum threshold appears to vary little between readers, and is in all cases high. Even a low proportion of ‘foreign’ terms degrades readability. | ||
Line 14: | Line 14: | ||
Exceptions to this are | Exceptions to this are | ||
* control | * [[control structure]]s: up to two levels of nesting, readers follow them; | ||
* | * [[glyphs]] other than the Roman alphabet or Arabic numerals; the reader either parses them as punctuation or mathematics (eg 2÷3), or ignores them. | ||
Two common features of programming languages obstruct this effect: | Two common features of programming languages obstruct this effect: | ||
Line 26: | Line 26: | ||
* assigning names only once; homonyms are confusing enough in natural languages; | * assigning names only once; homonyms are confusing enough in natural languages; | ||
* naming only objects that correspond to terms in the reader's vocabulary; | * naming only objects that correspond to terms in the reader's vocabulary; | ||
* using (in Dyalog, NARS2000, ngn/apl, dzaima/APL, GNU APL) anonymous [[dfn]]s (lambdas) to avoid assigning other names; | * using (in [[Dyalog]], [[NARS2000]], [[ngn/apl]], [[dzaima/APL]], [[GNU APL]]) anonymous [[dfn]]s (lambdas) to avoid assigning other names; | ||
* using [[tacit programming]] (in Dyalog, NARS2000, ngn/apl, dzaima/APL) to avoid using argument names in expressions. | * using [[tacit programming]] (in Dyalog, NARS2000, ngn/apl, dzaima/APL) to avoid using argument names in expressions. | ||
Line 36: | Line 36: | ||
* [http://archive.vector.org.uk/art10009900 Pair Programming With The Users] by Stephen Taylor, ''Vector'' 22:1 | * [http://archive.vector.org.uk/art10009900 Pair Programming With The Users] by Stephen Taylor, ''Vector'' 22:1 | ||
Why write specifications when you can collaborate with the users on executable code? Introduces the concept of 'semantic density' in constructing Domain-Specific Notations. | Why write specifications when you can collaborate with the users on executable code? Introduces the concept of 'semantic density' in constructing Domain-Specific Notations. | ||
[[Category:Essays]] |