Semantic density: Difference between revisions

From APL Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
Semantic density is a ''metric'' of the readability of a program by a non-programming domain expert.
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 variables or functions) 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.)
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 15: Line 15:


* [[control structure]]s: up to two levels of nesting, readers follow them;
* [[control structure]]s: up to two levels of nesting, readers follow them;
* characters other than the Roman alphabet or Arabic numerals; the reader either parses them as punctuation or mathematics (eg 2÷3), or ignores 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.


== 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. Paper presented at XP2006, Oulu, June 2006.
* [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.


[[Category:Essays]]
[[Category:Essays]]

Latest revision as of 06:10, 25 September 2020

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:

  1. as describing changes in the computer
  2. with reference to the domain

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 (e.g. names of variables or functions) 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.

Exceptions to this are

  • control structures: 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:

  • tokens that can't be omitted, such as void or function
  • most primitive functions have Roman-alphabet names

Certain writing techniques facilitate it:

  • assigning names only once; homonyms are confusing enough in natural languages;
  • naming only objects that correspond to terms in the reader's vocabulary;
  • using (in Dyalog, NARS2000, ngn/apl, dzaima/APL, GNU APL) anonymous dfns (lambdas) to avoid assigning other names;
  • using tacit programming (in Dyalog, NARS2000, ngn/apl, dzaima/APL) to avoid using argument names in expressions.

Further reading

  • Expository Programming by Paul Berry, Vector 22:3: "Kenneth Iverson used APL in the 60s to develop readable, executable models of key processes in different scientific fields"
  • 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."
  • 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."