4,494
edits
Semantic density: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
No edit summary |
mNo edit summary |
||
| (One intermediate revision 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 ( | 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 30: | Line 30: | ||
== 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 | |||
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]] | ||