Reasons to study concepts of PL

1. Reasons to study concepts of PL • Increased capacity to express programming concepts • Improved background for choosing appropriate languages • Increased ability to learn new languages • Understanding the significance of implementation • Increased ability to design new languages • Overall advancement of computing

2. Programming Domains • Scientific applications • Business applications • Artificial intelligence • Systems programming • Scripting languages • Special purpose languages

3. Language Evaluation Criteria 1. 2. Writability - Factors: - 3. Reliability - Factors: - • Readability • Writability • Reliability • Cost • others

4. Readability • The most important criteria • Factors: • Overall simplicity • Too many features is bad • Multiplicity of features is bad • Orthogonality • Control statements • Data type and structures • Syntax considerations

5. Orthogonality • Makes the language easy to learn and read • Meaning is context independent • Small number of constructs for generating many structures. • int, float, double, arrays and pointers ==> ? • Few exceptions to rules: e.g. why can function return a struct, but not an array? Why are all parameters pass-by-value, except arrays?

6. Writability • Simplicity and orthogonality • No duplication • Avoid too much complexity; so many constructs, most users don’t know what to use • Support for abstraction • Subprograms, structures • Expressivity • for vs. while, ++ vs. + 1

7. Reliability • Program should perform to specs under all conditions • Type checking of parameters, out-of-range errors • Exception handling • Aliasing • Generally bad, but can be useful for pass-by-reference • Readability and writability • Contorting the language to achieve an end can lead to errors.

8. Cost • Programmer training • Software creation • Compilation speed • Execution speed • Compiler cost (Java vs. Pascal) • Poor reliability • Maintenance

9. Other Evaluation Criteria • Portability • Generality • Well-definedness

10. Influences on language design • Computer architecture • We use imperative languages, at least in part, because we use von Neumann machines • Programming methodologies • 1950s and early 1960s: Simple applications; worry about machine efficiency • Late 1960s: People efficiency became important; readability, better control structures • Late 1970s: Data abstraction • Middle 1980s: Object-oriented programming • Early 1990s: Code re-use and libraries

11. Language Categories Language Design Trade-offs 1. Implementation Methods 1. • Imperative • Functional • Logic • Object-oriented (closely related to imperative) • Mark-up languages (html) don’t describe computations, so don’t count

12. Language Design Tradeoffs • Reliability versus cost of execution • Writability versus readability • E.g: APL • Flexibility versus safety • E.g: PASCAL allows pointers and integers to be treated identically. Good for pointer calculations, but dangerous.

13. Implementation Methods • Compilation • Interpretation • Hybrid

14. Compiled languages • Translate high-level program to machine code • Slow translation • Fast execution

15. Pure interpretation • No translation • Slow execution • Becoming rare • Though, see Python and Java!

16. Hybrid implementation systems • Small translation cost • Medium execution speed

17. Programming Environments • The collection of tools used in software development • UNIX • An old operating system and tool collection • Borland C++ • A PC environment for C and C++ • Smalltalk & Lisp • A language processor/environment • Microsoft Visual C++ • A large, complex visual environment

18. 2. Chapter 1