Language Evaluation P L COS 301. Fall School of Computing and Information Science University of Maine. Language Evaluation COS 301.

Size: px

Start display at page:

Download "Language Evaluation P L COS 301. Fall School of Computing and Information Science University of Maine. Language Evaluation COS 301."

Lesley Roberts
5 years ago
Views:

1 School of Computing and Information Science University of Maine Fall 2018

2 Outline

3 evaluation criteria

5 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

6 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

7 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

8 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

10 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

11 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;

12 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;

13 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

14 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

15 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

17 Is the program produced by the language reliable? : safety correctness features: type checking exception handling aliasing readability/writability interactions

18 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

19 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

20 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)

21 /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

23 Not what a compiler costs most are free anyway includes Time costs Direct monetary costs Other

24 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

25 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

26 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

27 Other evaluation criteria: Is the language portable? Is it general? Is the language well-defined?

29 , 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

Chapter 5. Names, Bindings, and Scopes

Chapter 5. Names, Bindings, and Scopes Chapter 5 Names, Bindings, and Scopes Chapter 5 Topics Introduction Names Variables The Concept of Binding Scope Scope and Lifetime Referencing Environments Named Constants 1-2 Introduction Imperative