COSC3308
Language evaluation criteria:
1. Readability (How easy it is to read and understand programs in
a certain language)
2. Writability (How easy it is to write programs after learning
the language first)
3. Reliability
4. Expressivity
5. Well-definedness
6. Modularity
7. Data types and structures
8. Input-Output facilities
9. Efficiency and Cost
10.Portability
11.Generality
A. Readability:
a. Most important criterion
b. Software Life Cycle development of 1970's -->
Recognition of importance of maintenance rather than
coding/writing and maintenance is determined in large part by
the readability
c. Factors:
Simplicity
Orthogonality
Control Statements
Data Structures
Syntax Considerations
Simplicity
1. A small number of elementary components
2. Absence of Feature Multiplicity
count = count+1
count++
++count
count += 1
3. Absence of Operator Overloading
a single operator symbol with more than one meaning
(like in SNOBOL, Smalltalk)
4. Lack of unnecessary features.
5. Oversimplification (like Assembly language)
Orthogonality
A small set of primitive constructs that can be combined
in a relatively small number of ways to build the control
and data structure of the language.
Furthermore, every possible combination is legal and
meaningful. This follows from a symmetry of relationships
among primitives.
IBM: A Reg, Memory
AR Reg1, Reg2
VAX: ADDl Opd1, Opd2 /* More orthogonal *?
More orthogonality --> Fewer rule exceptions -->
Higher degree of regularity --> Easier to learn/read
Ex: Pascal is not orthogonal: Many inconsistent type rules.
VAR and Value parameter types
Functions return only unstructured types
(at least in Standard Pascal, not in VAX, though)
Formal parameters must be named (and cannot be
a complete type specification)
File cannot be passed by Value.
Overorthogonality may cause problems (like in ALGOL68)
Unnecessary complexity (like if-clause and type statement
appearing on LHS of an assignment statement)
*** Good combination of Simplicity and limited orthogonality ***
Control Statements
Structured Programming revolution of 1970's was a reaction to
the poor readability caused by the limited control structures
of some languages of 1950's and 1960's.
It became widely recognized that indiscriminate use of GOTO
statements severely reduces readability.
1. No GOTO at all vs
2. Limited GOTO's
No forward branch except when used to form loops.
Targets are never too distant.
Their frequency of uses is limited.
Data Structures.
Allowing adequate facilities for defining data types and
data structures is another significant aid to readability.
Ex: Use of Boolean type: Flag=true
instead of: Flag=1 (Rather, unclear)
Use of Record type to represent employee records
rather than a parallel array scheme, which must be
used in a language w/o record.
Variety of structures (such as linked lists, Stacks, Queues,
and even trees) vs None/few (SNOBOL, PROLOG, Smalltalk)
Syntax considerations
1. Identifier form
Old FORTRAN: Only up to six chars for an id
Old ANSI BASIC: Only a single letter and a single digit
at most
The availability of connector characters such as _ or $
2. Special words significantly affect readability.
Delimiters for compound statements
Pascal: BEGIN END /* Bad */
C: { } /* Bad */
FORTRAN77: ENDIF ENDDO ENDWHILE
ADA: EndIf EndLoop
Conflict between Simplicity (from not having many
constructs) and greater readability (from having
more reserved words)
Keywords strictly reserved or not
FORTRAN: Not reseved at all
3. Form amd meaning
Designing statements so that their appearance at least
partially indicates their action is an obvious aid to
readability.
EX: FORTRAN: Assigned GOTO and Computed GOTO
(These two have similar appearance but
totally different meanings)
GOTO I, (10,20,30) : Assigned GOTO (I must assume
one of the label values)
GOTO (10,20,30), I : Computed GOTO ( I must be
an integer 1, 2, or 3)
B. Writability:
Measure of ease with which a language is used to create a program
by translating an algorithm in a chosen problem area)
1. It varies with the application area of the language.
APL: Good for dealing with matrix computation
COBOL: Not for matrix computation
Good for report generation
2. What affects readability also affects writability (because
writing a program often requires frequent reading of portions of
what is already written)
3. Simplicity and Orthogonality: Better than having relatively large
number of primitives that may easily lead to misuse/disuse.
Help programmers to learn a language quickly.
4. Abstraction support
Degree of abstraction allowed and the naturalness of expressions
used for operations and data structures as abstractions allow
natural and compact use of expressions without having to know
or specify most details.
Process abstraction (Subprograms).
Data Abstraction.
EX: A Binary Tree: FORTRAN: 3 parallel integer arrays
with integer nodes Pascal: Use an abstraction of a tree
node in the form of a simple
record with one integer and
two pointers.
5. Expressivity
Relatively convenient and consistent ways of specifying
computations for easy translation of an algorithm into a
program.
C: count++
ADA: and then (Short-circuit evaluation of a boolean)
Pascal: Use of 'For' loop instead of 'While' loop
for a counting loop.
Factors:
Use of structured programming constructs.
Use of consistent and compact notations and operators.
Like + or - instead of ADD or SUBTRACT.
Use of commonly used notations and expressions.
Use of distinct notations for distinct purposes:
(): For lists
[]: For array subscripts
{}: For Compound statements
C. Reliability.
Degree of how easy to write a correct program.
or how easy to detect incorrect programs.
or how preventive to write an incorrect programs.
1. Conflict with Efficiency
2. Redundancy for insuring consistency:
FORTRAN COMMON statements
Pascal, Ada: Parameter type specifications
3. Syntax must reflect semantics.
Bad example: PL/I: ON Condition on-unit
4. Make certain types of errors impossible or unlikely
Pascal: Compile-time type checking.
Altering FOR loop parameter variables.
Infinite WHILE Loops.
Restrictions on routine calls (Based on the Static
Scope Rule)
Restrictions on pointer variables
Ada: Prohibition of altering IN parameters or
referencing OUT parameters, making FOR loop
control variables local to the loop
5. Selection by name rather than by position:
X.Size instead of X(5)
6. Aliasing disallowed.
7. Readability and writability( for modifying a program in the
long run)
D. Cost
1. Training programmers
2. Writing programs
Good development environment
3. Compiling programs.
Simplicity by small set of constructs and static features
improve the difficulty and cost of compiling.
Bad ex: ADA (Huge general-purpose language) and PL/I (lesser
extent)
4. Running programs.
Simplicity by disallowing dynamic features (like recursive
procedure calls, dynamic pointer variables, dynamic scope
rules, dynamic arrays, dynamic types) will improve.
Compiler optimization.
5. Maintaining programs.
Readability is a key factor, especially in modifying programs.
E. Well-definedness
Lack of ambiguity of the syntax and semantic.
1. Improves cost of learning/compiling/reading/writing
2. Helps Standardization and good portability and reliability
(by reducing chances of making errors)
Bad ex: FORTRAN: DO 10 I = 1
DO10I = 1
3. Lack of unnecessary feature: 'Call by Name' of ALGOL60
F. Efficiency
Most excessively overemphasized criterion.
Generally, conflicts with Reliability.
1. Fast compiling and execution
2. Smaller space needed for program and data.
3. Affected by:
Simplicity by strict static binding
Compiler optimization
Compatibility with Hardware architecture
Bad EX: FORTRAN Array Subscript sequencing
G. Modularity
Makes it easy to design/write/modify large programs by modularizing
them via subprogram decomposition.
1. Affected by subprogram support and well-definedness and
use of default features.
2. Related to Scope rules, subprogram nestings, and Extensibility for
user-defined operators/DataTypes (like Pascal, C, ADA)