Map
Index
Random
Help
th

QuoteRef: hoarCA_1974

topics > all references > ThesaHelp: references g-h



ThesaHelp:
references g-h
Topic:
programming language design
Group:
goals for a programming system
Topic:
programmer productivity
Group:
requirement specification
Group:
program design
Topic:
understanding systems
Topic:
separate a module's interface specification from its implementation
Topic:
interface between program modules
Topic:
software documentation
Topic:
document-centered system
Topic:
programming style
Topic:
literate programming
Group:
debugging
Group:
programming notation
Topic:
type-safe and secure languages
Group:
security
Topic:
machine independent programming
Topic:
efficiency
Topic:
machine code and assembly language
Topic:
orthogonal extension and cartesian products
Topic:
error safe systems
Topic:
run-time assertions
Topic:
intermediate representation of code
Topic:
lexical analysis
Topic:
compiler
Topic:
transformation of programs
Topic:
abbreviated input
Topic:
software review
Topic:
comments
Topic:
compiler error checking
Topic:
abstraction in programming
Topic:
abstraction
Topic:
structured programming
Topic:
referential transparency
Topic:
localized understanding
Topic:
meaning vs. reference
Topic:
functional side effects
Topic:
notation for operations
Topic:
case statement
Topic:
sensitivity of software to change
Topic:
safe use of pointers
Topic:
domain specific language
Topic:
extensible languages
Group:
function
Topic:
declarative vs. procedural representation
Topic:
function call
Topic:
code optimization
Topic:
aliasing
Group:
parameters
Topic:
weak vs. strong type checking
Topic:
data types are not needed
Topic:
what is a computer
Topic:
science as measurement
Topic:
units
Group:
program proving
Topic:
user-centered design

Reference

Hoare, C.A.R., "Hints on Programming language design", Computer Systems Reliability, Infotech State of the Art Report, 20, 1974, pp. 507-534. Google

Quotations
352 ;;Quote: Algol was an improvement on its predecessors and nearly all of its successors
507 ;;Quote: the primary purpose of a programming language is to help the programmer
508 ;;Quote: it is hard to decide what a program does and specify it precisely and clearly
508+;;Quote: divide a complex task into simpler subtasks; specify purpose of each subtask; define efficient, precise interfaces between the subtasks
508 ;;Quote: a programming language should express the strategy of a program, its goals, and the details of coding and data
508 ;;Quote: a programming language should assist with the harmonious integration of separately developed modules; enforce conventions and disciplines
508 ;;Quote: documentation should be an integral part of design and coding
508 ;;Quote: the readability of programs is immeasurably more important than their writeability; self-documenting code; pleasant style
509 ;;Quote: debugging is tiresome, expensive, and unpredictable, particularly when integrating subprograms from many programmers
509 ;;Quote: a programming notation should reduce coding errors, and detect the remaining errors at compile-time
509 ;;Quote: a programming language is secure if it does not lead to machine or implementation effects that are inexplicable in terms of the language
509 ;;Quote: fast compilation for rapid turnaround; fast code for instrumenting a program
509 ;;Quote: a programming language must be simple; easily learned, easily used, easy to understand
510 ;;Quote: assembly code is simple, uniform, and easily defined; immediate feedback on time and space efficiency; surprisingly effective
511 ;;Quote: orthogonality -- hardware designers have learned more sense; but language designers are clever programmers and have not
512 ;;Quote: it is absurd to make elaborate security checks on debugging runs, and then remove them in production runs, when an erroneous result could be disastrous
512 ;;Quote: speed of compilation is important for debugging
513 ;;Quote: store program as tokens; skips lexical scan, reduces file size, allows full listing
513 ;;Quote: use precompile to save the compiler state after processing any initial segment of a program
514 ;;Quote: efficient object code is important; allows better-structured and clearer programs
515 ;;Quote: a compiler should produce efficient, compact code similar to a resolutely non-clever machine code programmer
516 ;;Quote: a machine-independent optimizer should be able to transform an inefficient program into a more efficient one with identical effects, expressed in the same language
516 ;;Quote: programming languages should emphasize readability by human beings, not computers
516+;;Quote: programming languages should not favour abbreviation of writing by default conventions and implicit assumptions
516 ;;Quote: review a program before compilation
516 ;;Quote: assembly programming uses simple conventions for comments; conventions for programming languages may be error-prone
518 ;;Quote: a compiler should pinpoint syntactic errors, diagnose the cause, and continuing checking the program
520 ;;Quote: principles of structuring -- transparency of meaning and purpose, recursive application, narrow interface, manifestness of structure
520+;;Quote: understand X+Y by recursively understanding each part independently; manifest structure, clear meaning and purpose
520+;;Quote: the interface between the parts of X+Y is a single number
521 ;;Quote: arithmetic expressions are highly efficient because of the extreme narrowness of the interface; a single number stored in a high-speed register
521 ;;Quote: for large operands, update is more efficient than replacement; provide notation, e.g., L1.append(L2)
523 ;;Quote: defined case construction for selection by value; no trace of compensating disadvantage
524 ;;Quote: machine code programming allows any change; errors may be hard to trace, especially with index registers
524 ;;Quote: the interface between two machine code instructions is the entire machine
524 ;;Quote: variables, arrays, files splits a machine into disjoint areas; updating one does not effect the others
525 ;;Quote: references have no meaning independent of a particular run of a program; cannot be input or output
525+;;Quote: references are like jumps, leading wildly from one part of a data structure to another; change can update any location
526 ;;Quote: block structure limits the scope of a variable; accessible from elsewhere only as a parameter
527 ;;Quote: design and implement a special-purpose programming language for every large-scale programming project; i.e., procedures and parameters
527+;;Quote: procedures and parameters afford all the major advantages of extensible languages, plus space efficiency
527+;;Quote: the language designer should give the greatest attention to procedures and parameters
527+;;Quote: calling sequences must be compact
528 ;;Quote: a variable should not be passed twice as distinct parameters; prohibited in standard FORTRAN
528 ;;Quote: type errors are a problem for machine programming; e.g., using an integer as an address
528+;;Quote: computer hardware can execute almost any sequence of instructions; the secret of its power, flexibility, simplicity, and reliability
530 ;;Quote: specify units for data types for consistency checks; e.g., height vs. weight, radians vs. degrees
531 ;;Quote: design one language feature at a time; improvement, efficient, documentation, security, examples, proof rule
531 ;;Quote: the language designer selects the best features instead of designing new ones; clear idea of scope, purpose, complexity
531 ;;Quote: listen carefully to what users want; understand what they really want; achieve the latter at a fraction of the cost of the former
531+;;Quote: cost-effective success in language design is progress in programming methodology


Related Topics up

ThesaHelp: references g-h (299 items)
Topic: programming language design (53 items)
Group: goals for a programming system   (21 topics, 983 quotes)
Topic: programmer productivity (57 items)
Group: requirement specification   (11 topics, 307 quotes)
Group: program design   (13 topics, 454 quotes)
Topic: understanding systems (48 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: interface between program modules (55 items)
Topic: software documentation (64 items)
Topic: document-centered system (12 items)
Topic: programming style (47 items)
Topic: literate programming (16 items)
Group: debugging   (10 topics, 333 quotes)
Group: programming notation   (14 topics, 221 quotes)
Topic: type-safe and secure languages (43 items)
Group: security   (23 topics, 874 quotes)
Topic: machine independent programming (13 items)
Topic: efficiency (96 items)
Topic: machine code and assembly language (49 items)
Topic: orthogonal extension and cartesian products (11 items)
Topic: error safe systems (76 items)
Topic: run-time assertions (25 items)
Topic: intermediate representation of code (31 items)
Topic: lexical analysis (14 items)
Topic: compiler (18 items)
Topic: transformation of programs (27 items)
Topic: abbreviated input (10 items)
Topic: software review (80 items)
Topic: comments (23 items)
Topic: compiler error checking (16 items)
Topic: abstraction in programming (67 items)
Topic: abstraction (62 items)
Topic: structured programming (27 items)
Topic: referential transparency (26 items)
Topic: localized understanding (43 items)
Topic: meaning vs. reference (49 items)
Topic: functional side effects (11 items)
Topic: notation for operations (18 items)
Topic: case statement (25 items)
Topic: sensitivity of software to change (44 items)
Topic: safe use of pointers (102 items)
Topic: domain specific language (8 items)
Topic: extensible languages (71 items)
Group: function   (12 topics, 232 quotes)
Topic: declarative vs. procedural representation (54 items)
Topic: function call (28 items)
Topic: code optimization (54 items)
Topic: aliasing (28 items)
Group: parameters   (10 topics, 145 quotes)
Topic: weak vs. strong type checking (42 items)
Topic: data types are not needed (8 items)
Topic: what is a computer (62 items)
Topic: science as measurement (36 items)
Topic: units (23 items)
Group: program proving   (10 topics, 311 quotes)
Topic: user-centered design (65 items)

Collected barberCB 5/00
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.