4,500
edits
Miraheze>Adám Brudzewsky No edit summary |
mNo edit summary |
||
(8 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
Semantic | 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 ( | This is possible when a sufficiently high proportion of the tokens (e.g. 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 | * 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. | ||
== Further reading == | == Further reading == | ||
* [http://archive.vector.org.uk/art10000980 Expository Programming] by Paul Berry, ''Vector'' 22:3 | * [http://archive.vector.org.uk/art10000980 Expository Programming] by Paul Berry, ''Vector'' 22:3: "[[Ken Iverson|Kenneth Iverson]] used APL in the 60s to develop readable, executable models of key processes in different scientific fields" | ||
[[Ken Iverson|Kenneth Iverson]] used APL in the 60s to develop readable, executable models of key processes in different scientific fields | * [http://www.5jt.com/articles/40440021.pdf Software Development as a Collaborative Writing Project] by Brian Bussell (Director of Pensions, Norwich Union Life) and Stephen Taylor, paper presented at XP2006, Oulu, June 2006: "Writing software is more like drafting legislation or writing a screenplay than it is like engineering." | ||
* [http://www.5jt.com/articles/40440021.pdf Software Development as a Collaborative Writing Project] by Brian Bussell (Director of Pensions, Norwich Union Life) and Stephen Taylor | * [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." | ||
Writing software is more like drafting legislation or writing a screenplay than it is like engineering. | |||
* [http://archive.vector.org.uk/art10009900 Pair Programming With The Users] by Stephen Taylor, ''Vector'' 22:1 | [[Category:Essays]] | ||
Why write specifications when you can collaborate with the users on executable code? Introduces the concept of 'semantic density' in constructing Domain-Specific Notations. |