Group:
program representation
Group:
Thesa programming system
Group:
software maintenance
Group:
systems
Topic:
decomposition of a system into levels
Topic:
descriptive naming
Topic:
display console as a user interface
Topic:
ease of learning
Topic:
handling complexity
Topic:
information as knowledge
Topic:
learning a programming language
Topic:
literate programming
Topic:
localized understanding
Topic:
mental models, consistency, and interface metaphors
Topic:
minimal language systems
Topic:
minimal manuals and guided exploration
Topic:
open systems
Topic:
program listing
Topic:
program source as truth
Topic:
programming style
Topic:
reusable programming
Topic:
software documentation
Topic:
software models of reality
Topic:
source-rich system
Topic:
spatial vs. temporal representation
Topic:
type reflection and introspection
Topic:
uniform language systems
Topic:
user-defined languages
Topic:
user maintenance
Topic:
words defined by words
| |
Summary
Programs written under existing general purpose programming systems are difficult to understand and use, especially by non-programmers. Yet programs which can't be understood can't be maintained or modified. Such programs become obsolete as their environment changes.
Program representations should inform the attentive reader without requiring specialized knowledge. True understanding implies a model which allows the reader to predict the effect of program modification. Understanding is helped by readable programs, internal structure, static descriptions, consistent program formats, and explicitly stated information. (cbb 5/80)
Subtopic: understanding 
| Quote: understanding: there are many ways to say or do something, but all are the same [»browGS_1972]
| | Quote: understanding an event means fitting it into a preconceived scheme of thought; could be science or a private delusion [»weinGM_1982]
|
Subtopic: comprehensive understanding
| Quote: a system must be comprehensible to a single individual if it is to serve the creative spirit [»ingaDH8_1981a]
| | Quote: a proficient user must develop a comprehensive internal model of a programming language [»richF12_1977]
| | Quote: need expressive language for setting security policy and understanding the consequences of security-related decisions [»yeeKP12_2002]
| | Quote: a programming language expresses concepts and systems in a way that people can understand
| | Quote: each member of a programming team must be able to understand unambiguously what his colleagues designed
|
Subtopic: understanding task
| Quote: a computer-aided design system should augment and stimulate the designer without awareness of highly complex computer programs; think almost entirely at the concept level within a field of interest; continually extended [»rossDT_1963]
| | Quote: allow virtual devices that do not correspond to hardware devices; capabilities may be scattered among multiple devices, one device may contain unrelated capabilities; want an understandable interface [»britKH3_1981]
|
Subtopic: understanding data
| Quote: XML should be understandable and useable without a universal schema [»boswA10_2005]
| | Quote: explicitly represent and enforce all database issues of concern to the user community; not hidden in applications [»coddEF_1990]
| | Quote: self-contained, logical level of abstraction in a database [»coddEF_1990]
| | Quote: compare values to interrelate database objects instead of using pointers; well understood by all users [»coddEF_1990]
|
Subtopic: understanding execution
| Quote: a system should provide clear, accurate information about what is happening and its progress toward completion [»karaCM12_1998]
| | Quote: a debugger, like a programming environment, should effortlessly show the connections in a program; e.g., the original source of a value [»ungaD4_1997]
| | Quote: the monitor tubes show the current state of the machine
| | Quote: need conventions to reduce uncertainty about a machine's state; computers have very great flexibility [»turiA3_1951]
|
Subtopic: understanding programs
| Quote: the software crisis is due to our human limitations in handling complexity; to solve the problem, we must simplify the program text [»wulfWA_1977a]
| | Quote: complex software consists of simple parts and relations; the programmer's goal is human comprehension [»knutDE2_1984]
| | Quote: how should software be published? code is only fit for mechanical execution [»dijkEW_1979]
| | Quote: open system is understandable: reasons for action, help, commands [»robeG5_1981]
| | Quote: programming is inhumanly hard; because text strings are a poor representation for programs [»edwaJ10_2005]
| | Quote: to make programming easy one must make coding comprehensible [»glenAE2_1953]
|
Subtopic: internal regularities
| Quote: collar variables are variables that determine the behavior of the rest of the system [»menzT1_2007]
|
Subtopic: understanding formal program
| Quote: produce an informal specification in parallel with a formal project description; helps clarify the formal text [»boweJP4_1995]
| | Quote: a good specification is at a high enough level to be understandable and precise enough to be complete; difficult to achieve [»swarW7_1982]
|
Subtopic: programming language
| Quote: need a programming language that is easy to understand and efficient to execute; currently too detailed or too inefficient [»tarjRE3_1987]
| | Quote: a programming language should express the strategy of a program, its goals, and the details of coding and data [»hoarCA_1974]
| | Quote: a programming language must be simple; easily learned, easily used, easy to understand [»hoarCA_1974]
| | Quote: programming languages should emphasize readability by human beings, not computers [»hoarCA_1974]
| | Quote: Simula designed as a language for system description, understanding, and simulation [»nygaK10_1986]
| | Quote: ALGOL 60 is almost an LR(1) grammar; would make it unambiguous [»knutDE6_1965]
| | Quote: algebraic notation makes programs easy to read and mentally check; reduces programming error and increases productivity [»glenAE2_1953]
|
Subtopic: understanding object-oriented
| Quote: Law of Demeter reduces method complexity and nested message sending; increases number of messages and their arguments [»liebKJ9_1989]
| | Quote: relax the Law of Demeter by declaring acquaintance classes; documents dependencies [»liebKJ9_1989]
|
Subtopic: understanding routines
| Quote: use routines to document code; e.g., a descriptive name can document a short routine [»mccoS7_1998]
| | Quote: a library makes it easier to understand programs; standardized conventions and larger units [»wheeDJ6_1949]
|
Subtopic: separate languages
| Quote: a programmable editor should not use the same commands for editing and programming; otherwise the programs are hard to read [»stallRM6_1981]
| | Quote: secure DNS resolver in 10 lines of code; easier to understand than BIND's security policy [»jimT5_2000]
|
Subtopic: avoid abbreviation
| Quote: programming languages should not favour abbreviation of writing by default conventions and implicit assumptions
|
Subtopic: simplification not possible
| Quote: high-level languages free programs from their accidental complexity but not their essential complexity [»abboRJ3_1990]
| | Quote: finite automata do not support hierarchical design or concurrency; large, real-time systems are impossible to understand [»benvA9_1991]
|
Subtopic: loss of understanding
| Quote: natural programs are no longer understandable, while rational programs are understandable [»millH_1973]
| | Quote: plex structures become so elaborate and interwoven that they are impossible to understand; need to automatically translate from language to plex structures [»rossDT_1963]
| | Quote: programming is confusing for first-time users; it makes smart people feel dumb [»instrumentcontrol]
| | Quote: pattern matching in SNOBOL4 can be very arcane, even to the point of needing the system's source listings [»grisRE4_1980]
|
Subtopic: computers as unconventional
| QuoteRef: dijkEW_1979 ;;444 "I expect for computing scientists the most convenient way of thinking and understanding to be rather unconventional
|
Subtopic: understanding not needed
Quote: understanding a plan structure is not critical to program comprehension; e.g., can use control-flow instead
[»gilmDJ9_1987]
|
Related Topics
Group: program representation (25 topics, 659 quotes)
Group: Thesa programming system (11 topics, 561 quotes)
Group: software maintenance (14 topics, 368 quotes)
Group: systems (17 topics, 530 quotes)
Topic: decomposition of a system into levels (49 items)
Topic: descriptive naming (29 items)
Topic: display console as a user interface (10 items)
Topic: ease of learning (38 items)
Topic: handling complexity (60 items)
Topic: information as knowledge (17 items)
Topic: learning a programming language (15 items)
Topic: literate programming (16 items)
Topic: localized understanding (43 items)
Topic: mental models, consistency, and interface metaphors (49 items)
Topic: minimal language systems (12 items)
Topic: minimal manuals and guided exploration (44 items)
Topic: open systems (33 items)
Topic: program listing (14 items)
Topic: program source as truth (17 items)
Topic: programming style (47 items)
Topic: reusable programming (77 items)
Topic: software documentation (64 items)
Topic: software models of reality (24 items)
Topic: source-rich system (27 items)
Topic: spatial vs. temporal representation (21 items)
Topic: type reflection and introspection (28 items)
Topic: uniform language systems (25 items)
Topic: user-defined languages (42 items)
Topic: user maintenance (13 items)
Topic: words defined by words
(25 items)
|
