159.331 Programming Languages & Algorithms

1. 159.331 Programming Languages & Algorithms Lecture 04 - Aspects of Programming Languages - Part 3 Prog Lang & Alg

2. Communication Media • Programming languages are a communications media between you and the computer (and other programmers) • Human-to-Human • Machine-to-Machine - may be broken down into several stages to make problem feasible eg multi pass compiler Prog Lang & Alg

3. Algorithms & Languages • Reminder - Algorithms - recipes for solving a problem - we will look at several later. • Algorithmic languages • Tend to concentrate on sets of instructions (ie are very un-verbose!) • Example is APL - “ A Programming Language” • Powerful (compact) syntax for expressing algorithms • Hard to read by humans Prog Lang & Alg

4. Managing Complexity • Make languages not just readable but modular so humans can hold one piece in their minds at a time. • Some ideas that came along: • Procedures (functions or subroutines) • Modules (packages or maybe just single file of code) • Abstract data types (and later objects) • Structured Programming - exorcism of the goto • Rapid Prototyping VHLL - ease of development at (considerable) cost of performance efficiency Prog Lang & Alg

5. Problem Decomposition • Divide and Conquer (or rule) (Divide et impera!) • Various strategies - sometimes a recursive solution is most natural • For example - sorting a list • Split list into sublists • Sort the sublists • Finish when no more sorting to be done (escape hatch) Prog Lang & Alg

6. Prog Lang & Alg

7. Problem Decomposition • Useful to make programs from smaller more understandable pieces • The pieces can hopefully be reused! • To decompose problems we make use of: • Procedures • Recursion • Parameter passing • These features are available in almost all high level languages and even assembly languages Prog Lang & Alg

8. Abstraction • Ignoring irrelevant details “in a safe way” • What details? • often internal data representation eg year part of a “Date” • Hide this via an Interface (procedural or OO) • Define an Abstract Data Type - ADT (or sometimes an “object”) to encapsulate and hide irrelevant detail • The user does not look inside the ADT or object - instead just trusts its interface • Package, Module as they are known in Ada and Modula-2 or Module in modern Fortran or Package in Java are mechanisms for organising ADTs • Compilers make this all work by hiding secret names Prog Lang & Alg

9. Contextual Checking • Although syntax errors usually easy to spot (by both machines and humans) • eg “Him of quickly five” makes no sense in English • begin ) end makes no programming sense • Contextual errors harder to identify: • “What colour are elephants’ antlers?” • Need some context to know this is wrong • Few contextual correctness tests can be done properly • Many proved to be recursively unsolveable - means that no algorithms exist, even in theory, that does them properly! Prog Lang & Alg

10. Possible Contextual Checking • So what can a compiler do? • Check for undeclared identifiers • Check parameter numbers against definitions • We can also check against variable and identifier types - (strong and weak type checking) • Some possible heuristics we can check too Prog Lang & Alg

11. Type Checking • Variables have values in their domains • a logical value is in {true,false} • 16 bit integer is in {-32768,…,0,…,32767} • The domains are called data types • A compiler can check the usage of these data types - so eg “only int16s are used where int16s are expected” • If it picks up all inconsistencies we say it applies “Strong type checking” • Otherwise it applies “Weak type checking” • Or indeed none! Prog Lang & Alg

12. C and C++ Types • One of the (many) problems with C and C++ based languages is the weak type checks • You (the programmer) can coerce or cast data types and circumvent what little checking there is. eg int i; double d = 10.0; i = (int *) (&d); • Although this general capability is powerful and sometimes useful for performance - it it very unsafe! • The C and C++ compiler are unable to protect you from your own mistakes Prog Lang & Alg

13. Type Checking Languages • Some languages support strong type checking • Ada, Modula-2 do. • The idea also can be applied to functional languages as well as procedural and OO ones • Eiffel (OO) and Miranda (functional) have strong checking • Logic languages generally do not. Prog Lang & Alg

14. Heuristic Contextual Checks • Checks based on common experience rather than proven to be completely correct in all cases • Often implemented with compiler switches or flags - so you can turn them off and ignore a warning if you choose • An example would be to test whether a recursive routine has an escape hatch (termination possibility) • The compiler might find an escape hatch via some heuristic but if it is unreachable it is still an error. These ideas take us into compiler methodology - beyond scope of this paper. Prog Lang & Alg

15. Program Processing • Interpretation vs Compilation • You have used C and C++ compilers • You may also have come across a Matlab or Prolog interpreter • A compiler makes a compiled (complete) program (usually you get faster execution of your program this way. Also allows you to release your “binaries” only.) • An interpreter runs as it reads the source (usually a bit slower, but able to interact with you and the source code at run time - often useful to give you diagnostics) Prog Lang & Alg

16. Prog Lang & Alg

17. Modern compilers often do the link editing for us automatically. Prog Lang & Alg

18. Prog Lang & Alg

19. Prog Lang & Alg

20. Macro Preprocessing • Macros do some simple textual manipulation before compilation actually starts • eg in C: #define MAX_ARRAY_SIZE 10 • #include “myfile.h” often useful • #ifdef UNIX … #else … #endif • can be helpful in older languages (eg ratfor) but beware - macros are error prone as they can have unintended effects • Better (safer) to use the language compiler’s type checking • See m4 and cpp macro preprocessors Prog Lang & Alg

21. Prog Lang & Alg

22. Debugging Tools & Environments • You may have used these as part of an integrated program development environment such as Builder or Eclipse • There are separate tools such as: • Trace, • dbx, gdb • Will interoperate with compilers to allow you to step through a program execution to find bugs • See Manual page - man gdb on a Unix platform. Prog Lang & Alg

23. Other Tools • Apart from program source code editors like vi or emacs there are some other common program maintenance tools, including: • make and imake to control complex compilation • prof/gprof to assess execution performance • RCS, CVS source code tree maintenance • ranlib - tool for managing binary object libraries • A particular language/environment product may also provide these capabilities • See magazines like ACM Queue or Dr Dobbs Journal for discussion on issues and relative merits Prog Lang & Alg

24. Can classify programming languages according to paradigm they support A paradigm is a coherent set of methods for handling a given type of problem - ie the problem domain. It is a mode of thinking and moulds the design process. Four widely agreed programming paradigms: imperative; object-oriented; functional; and logic Many minor ones and new ones being debated Additional problem domains require additional paradigms - eg parallel and distributed programming could be said to be such a domain. A paradigm for a specific problem domain is called a programming model Aspects Summary -I Prog Lang & Alg

25. Aspects Summary - II • Communication between human and machine requires great clarity and precision and can be unexpectedly difficult • Modern programming languages have the task of assisting the user in managing and reducing complexity of the programming task, without unduly restricting expressivity, and without causing undue loss of efficiency. Prog Lang & Alg

26. Aspects Summary - III • Techniques for handling complex problems successfully are: subdividing the problem (decomposition); ignoring irrelevant detail in a safe way (abstraction) and having an independent agent check the internal consistency (context checking). • An interface is a formalized way of accessing an object, with the user on one side and the object on another. • A type is a set of values with operations defined on them. It can also be viewed as a set of operations with their domains. • Strong type checking will signal all domain inconsistencies, weak type checking will only signal some. Prog Lang & Alg

27. Aspects Summary IV • Since any serious program is read many more times during its lifetime that it is written, readability is more important than writeability. • An interpreter is a program that can read, analyse and execute commands of a high-level language. • A compiler translates these commands into machine instructions rather than executing them. • A macro processor produces compiler input by scanning a program text and replacing names in it by specified strings. Macro preprocessors can simplify programming but are easily abused. Prog Lang & Alg

28. Summary • Bal & Grune Chapter 1 • Sebesta Chapters 1-3 and parts of chapters 4, 5 and 6. • Next - Imperative/Procedural programming languages Prog Lang & Alg