School of Computing and Information Science University of Maine Fall 2018
Outline 1 2 3 4 5
evaluation criteria
Early (pre-1970s): more important for machine to read code easily After: realized SW maintenance cost development cost Memory helped readability: Compilers/interpreters need system memory Ones for more readable l can be large Aspects of readability: Simplicity Orthogonaility Syntax
Simplicity Size of language feature set readability Subsets: Can readability E.g., writer & reader familiar with different ones Canonical features vs feature multiplicity: i=i+1; i++; ++i; i+=1; i=+1; Operator overloading readability E.g., + for floating point, integer, string concatenation j = "hi" + 4; Especially confusing: user-defined overloading
Orthogonality Large feature set or small primitive constructs that can be combined? Canonical: one and only one way to express something Primitive constructs all treated alike All combinations legal with all constructs All combinations behave same way More canonical readability Example: IBM instruction set had 2 opcodes for addition (reg reg, reg mem) DEC VAX had one Non-orthogonality in C C functions: can return struct but not array Struct member: can be anything except void or struct of same type Array elements: can be any data type except void or function Parameters: passed by value... except arrays
Syntax Identifiers impact readability Length Characters allowed Compound statement syntax: Deeply-nested {} (C-like) or () (Lisp-like) Deeply-indented Python code Choice of delimiters (spaces in Python, e.g.) Different meaning for same keyword readability static used inside C function variable retains memory/value across function invocations static used outside C function variable/function visible only within same file
How easy is it for a programmer to write a program? Could depend on purpose, level of language: e.g., C vs Python for writing a graphics-intensive game writing an embedded controller Also depends on: Simplicity and orthogonality Support for abstraction Expressivity
Simplicity/orthogonality Generally writability Large feature set, non-orthogonality may accidental use of unknown/inappropriate features E.g., C++ cout «(1 «2); cout «1 «2;
Simplicity/orthogonality Generally writability Large feature set, non-orthogonality may accidental use of unknown/inappropriate features E.g., C++ cout «(1 «2); prints 4 (2 0 shifted 2 times = 2 2 ) cout «1 «2;
Simplicity/orthogonality Generally writability Large feature set, non-orthogonality may accidental use of unknown/inappropriate features E.g., C++ cout «(1 «2); prints 4 (2 0 shifted 2 times = 2 2 ) cout «1 «2; prints 12
Abstraction Abstraction allows treating complex structures/operations as black boxes Support for abstraction writability Procedural abstraction: Output specified in terms of its relationship to inputs only Internals of procedure are opaque E.g.: sin(), cos(), user-defined procedures, etc. Data abstraction: Use representation of data appropriate for problem, regardless of implementation An interpretation of the underlying bits E.g.: floating point instead of bits arrays instead of contiguous integers objects user-defined data types
Expressivity Can language express what is needed for problem? Does language have convenient ways to specify operations? Number, power of operators expressivity Number predefined functions expressivity E.g.: COBOL: lots of operations for different file types APL: lots of math operations, convenient for mathematicians
Is the program produced by the language reliable? : safety correctness features: type checking exception handling aliasing readability/writability interactions
Type checking Type checking: insuring that operands compatible with operator data compatible with variables variables compatible with variables arguments compatible with formal parameters Compile-time or runtime? Runtime checking: expensive (e.g., C, etc.: none) Compile-time checking: may writability (e.g., Python, Lisp: little none) Strong, compile-time type checking reliability, readability Runtime type casting (Python, Lisp, others) writability, reliability
Exception handling Ways to handle runtime errors Most l have some way of handling exceptions Some don t (e.g., C) Security, correctness impacted by lack of exception handling
Aliasing Two more more names for or pointers to same thing memory location (e.g., pointer, name) object (reference, name) Aliasing reliability Most l suffer from this pass-by-reference parameters assigning references to multiple variables assigning pointers to multiple variables pointer computation arriving at same values Problem: multiple accesses to same location/object May not be obvious: change one, other magically changes Could lead to race conditions (in shared, multip environment)
/writability interactions Lack of expressiveness in language unnatural/convoluted algorithms and p Leads to reliability, readability Poor readability itself reliability readability makes it hard to catch/fix bugs, logic errors E.g.: APL, Perl facetiously: write-only l C: R2D2 s diary
Not what a compiler costs most are free anyway includes Time costs Direct monetary costs Other
Not what a compiler costs most are free anyway includes Time costs : Training programmer or programmer s time to learn Time required to write programs using the language Compilation speed (wastes time) Efficiency of execution issues bugs/security flaws time to fix Maintenance time Direct monetary costs Other
Not what a compiler costs most are free anyway includes Time costs : Training programmer or programmer s time to learn Time required to write programs using the language Compilation speed (wastes time) Efficiency of execution issues bugs/security flaws time to fix Maintenance time Direct monetary costs : Programmer s/maintainer s pay Lost opportunity due to delays selling product Not getting time-critical solution on time issues bugs/security flaws lost money Other
Not what a compiler costs most are free anyway includes Time costs : Training programmer or programmer s time to learn Time required to write programs using the language Compilation speed (wastes time) Efficiency of execution issues bugs/security flaws time to fix Maintenance time Direct monetary costs : Programmer s/maintainer s pay Lost opportunity due to delays selling product Not getting time-critical solution on time issues bugs/security flaws lost money Other : Privacy breaches Data loss Injury/death
Other evaluation criteria: Is the language portable? Is it general? Is the language well-defined?
, writability, reliability, and cost are all important However, trade-offs sometimes necessary: vs writability Polymorphism/operator overloading (+ in Python, e.g.) Special-purpose operators (e.g., APL) Complex language (e.g., PL/I) vs reliability Pointers in C, C++ Untyped l vs cost Quicker to build applications in Python, Lisp Runtime type checking, exception handling