Nancy Leveson, Sept. 1999 rogramming Languages As difficult to discuss rationally as religion or politics Prone to extreme statements devoid of data Examples students that have had a prior exposure to baSIc, as It is practically impossible to teach good programming to potential programmers they are mentally mutilated beyond hope of regeneration. "(Dijkstra The use of COBOL cripples the mind; its teaching should therefore, be regarded as a criminal offence. "(Dijkstra) Like anything else, decision making should be a rational process based on the priorities and features of the project
Copyright Nancy Leveson, Sept. 1999 Programming Languages As difficult to discuss rationally as religion or politics. Prone to extreme statements devoid of data. Examples: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC; as potential programmers they are mentally mutilated beyond hope of regeneration." (Dijkstra) "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." (Dijkstra) Like anything else, decision making should be a rational process based on the priorities and features of the project. � c
Nancy Leveson, Sept 1999 Some decision factors Features of application Hard real time? Not just efficiency Predictability(need to guarantee deadlines will be met) High assurance? Portability? Maintainability? Others? Features of development environment Availability of programmers, compilers, development tools? Schedule constraints Others
Copyright Nancy Leveson, Sept. 1999 Some Decision Factors c Features of application: Hard real time? Not just efficiency Predictability (need to guarantee deadlines will be met) High assurance? Portability? Maintainability? Others? Features of development environment: Availability of programmers, compilers, development tools? Schedule constraints? Others? �
Nancy Leveson, Sept 1999 Relationship between Pl and correctness Decreasing emphasis as an explicit design goal and research topic Masterability Not complex: programmers understand it in its entirety The most important decisions in language design concern what is to be left out. "( Wirth) Powerful features oK only if easy to use correctly Balance against need to keep language simple Natural Language should not surprise us in any of its effects Should correspond to our experience with natural languages, mathematics, and other PLs
Copyright Nancy Leveson, Sept. 1999 Relationship between PL and Correctness Decreasing emphasis as an explicit design goal and research topic. Masterability Not complex: programmers understand it in its entirety The most important decisions in language design concern what is to be left out." (Wirth) Powerful features OK only if easy to use correctly. c Balance against need to keep language simple "Natural" Language should not surprise us in any of its effects. Should correspond to our experience with natural languages, mathematics, and other PLs �
Relationship between pl and correctness(2 Error proneness Language design should prevent errors Should be difficult or impossible to write an incorrect program If not possible, then allow their detection(as early as possible) Need for general principles and hypotheses so can predict error-prone features and improve language design Some hypotheses and data about Go Global variables Pointers Selection by position(long parameter lists Defaults and implicit type conversi Attempts to interpret intentions or fix errors Meaning of features should be precisely defined(not dependent on compiler
Copyright Nancy Leveson, Sept. 1999 Relationship between PL and Correctness (2) Error Proneness Language design should prevent errors. Should be difficult or impossible to write an incorrect program. If not possible, then allow their detection (as early as possible) Need for general principles and hypotheses so can predict error-prone features and improve language design. Some hypotheses and data about: Go to Global variables Pointers Selection by position (long parameter lists) Defaults and implicit type conversion Attempts to interpret intentions or fix errors c Meaning of features should be precisely defined (not dependent on compiler. �
Relationship between PL and Correctness ( 3) Understandability The primary goal of a programming language is accurate communication among humans Readability more important than writeability Well"punctuated"(easy to directly determine statement types and major subunits without intermediate inferences) Use of distinct structural words(keywords, reserved words for distinct concepts(no overloading, e. g, for equal, assignment) Avoidance of multiple use of symbols unless serve completely analogous functions(e.g, commas as separators, parentheses for grouping) Necessary to be able to see what is being accomplished at a higher level of abstraction Permit programmers to state their "intentions"along with instructions necessary to carry them out
Copyright Nancy Leveson, Sept. 1999 Relationship between PL and Correctness (3) Understandability "The primary goal of a programming language is accurate communication among humans." Readability more important than writeability. Well "punctuated" (easy to directly determine statement types and major subunits without intermediate inferences) Use of distinct structural words (keywords, reserved words) for distinct concepts (no overloading, e.g., = for equal, assignment) Avoidance of multiple use of symbols unless serve completely analogous functions (e.g., commas as separators, parentheses for grouping). Necessary to be able to see what is being accomplished at a higher level of abstraction. Permit programmers to state their "intentions" along with instructions necessary to carry them out. � c
Relationship between PL and Correctness (4) ° Maintainability Locality--possible to isolate changes Self-documenting Programming decisions should be recorded in program, independent of external documentation Good comment convention freedom to choose meaningfu variable names etc User-defined types and named constants e.g., type direction=(north, south, east, west) Explicit interfaces Should cater to construction of hierarchies of modules
Copyright Nancy Leveson, Sept. 1999 Relationship between PL and Correctness (4) Maintainability Locality -- possible to isolate changes. Self-documenting Programming decisions should be recorded in program, independent of external documentation. Good comment convention, freedom to choose meaningful variable names, etc. User-defined types and named constants e.g., type direction=(north, south, east, west) Explicit interfaces Should cater to construction of hierarchies of modules � c
Relationship between PL and Correctness (5) Checkability Every error should transform a correct program into one whose errors are detectable by the system All error detection based on redundancy(but some forms can cause errors EXamples of userful redundancy type declarations and type checking declarative redundancy variance conditions or assertions Run-time assertions, exception handling hecking subscripts vs array bound case selector vs. case bounds
Copyright Nancy Leveson, Sept. 1999 Relationship between PL and Correctness (5) Checkability Every error should transform a correct program into one whose errors are detectable by the system. All error detection based on redundancy (but some forms can cause errors). Examples of userful redundancy: type declarations and type checking declarative redundancy invariance conditions or assertions Run-time assertions, exception handling checking subscripts vs. array bounds case selector vs. case bounds � c
Relationship between PL and Correctness(6) Genera High-level languages take many decisions out of programmers hands One reason they are so fiercely resented by experienced programmers Language should restrict programmer to decisions that really matter Decisions should be recorded in program independent of external documentation Simplicity of language less important than ability to write conceptually simple programs
Copyright Nancy Leveson, Sept. 1999 Relationship between PL and Correctness (6) General High-level languages take many decisions out of programmer’s hands. One reason they are so fiercely resented by experienced programmers. Language should restrict programmer to decisions that really matter. Decisions should be recorded in program independent of external documentation. Simplicity of language less important than ability to write conceptually simple programs. � c
Green:Design and Use of PLs Clarifying the psychological processes of using programming languages will, I believe, clarify the requirements of language design and of environmental support Some examples of structured programming hypotheses Control structures should be hierarchical. Thus they should be nested, rather than allowed to have arbitrary branching In this way, successive layers of detail can be added The comprehensibility of hierarchically constructed programs will be easier, since they can be understoof by a reverse process-understand the outer layer, then the inner layers, etc inter-relations between parts will be simple use the These programs will be easy to modify bec Have accepted these hypotheses but have never been validated
c Copyright Nancy Leveson, Sept. 1999 Green: Design and Use of PLs "Clarifying the psychological processes of using programming languages will, I believe, clarify the requirements of language design and of environmental support." Some examples of structured programming hypotheses: Control structures should be hierarchical. Thus they should be nested, rather than allowed to have arbitrary branching. In this way, successive layers of detail can be added. The comprehensibility of hierarchically constructed programs will be easier, since they can be understoof by a reverse process -- understand the outer layer, then the inner layers, etc. These programs will be easy to modify because the inter-relations between parts will be simple. Have accepted these hypotheses but have never been validated. �
Green: Program Comprehension Cites experiments(atheoretical")that evaluate only current programming practice More interesting question: Can we elucidate underlying psychological principles to allow generalization of results to other classes of information structure in programming? Hypothesis 1: If one language is better than another, it is always better, whatever the context Hypothesis 2: Every notation highlights some type of information at the expense of others the better notation for a given task is theone that highlights the information that given task needs More generally, the comprehensibility of a notation may depend on the number and complexity of mental operations required to extract needed information
Copyright Nancy Leveson, Sept. 1999 Green: Program Comprehension Cites experiments ("atheoretical" ) that evaluate only current programming practice. More interesting question: Can we elucidate underlying psychological principles to allow generalization of results to other classes of information structure in programming? Hypothesis 1: If one language is better than another, it c is always better, whatever the context. Hypothesis 2: Every notation highlights some type of information at the expense of others; the better notation for a given task is theone that highlights the information that given task needs. More generally, the comprehensibility of a notation may depend on the number and complexity of mental operations required to extract needed information. ���
