Program CS2130 Language Concepts and Paradigms
Lecture 1 -- Introduction Module Outline: Credits: 10 LEARNING OUTCOMES Knowledge and understanding of programming paradigms alternative or complementary to the basic sequential imperative paradigm Understanding of programming language structure, emphasising the role of abstraction and its significance for practical software design and construction Practical ability with some of the languages and paradigms discussed Understanding of software concepts and acquisition of associated skills that will be of value in a range of subsequent modules. CONTENT Fundamental programming language concepts: values, types; binding, scope, visibility, variables, storage, lifetime; expressions, commands, state, function and procedure abstraction, parameter mechanisms. Review of encapsulation and information hiding: packages, abstract objects, abstract data types, reusability via generic abstraction. Object oriented programming in Ada 95, applications e.g. streams and controlled objects, comparison with other languages. Concurrent programming using Ada 95, comparison with Java. Topics will be illustrated by examples and practical exercises using a variety of appropriate languages, e.g. Pascal, Java, C, C++, Ada 95, Lisp, Prolog, SR. PREREQUISITES CS1110 Introduction to Systematic Programming CS1210 Data Structures and Algorithms CS2110 OOP with Java LEARNING PROVISION Lectures: 22 hours Practical classes: 5 hours Further study and examination: 73 hours Students will be expected to complete practical programming exercises on all major topics covered. Practical work will be assessed through coursework assignments and related examination questions. ASSESSMENT Formal examination: 75% (1.5 hours) Continuous assessment: 25% Reading DA Watt (with W Findlay) Programming Language design Concepts Wiley (2004) R W Sebasta Concepts of Programming Languages (5th ed.) Pearson Educ. 2002 L Wilson & R Clark, Comparative Programming Languages (3rd ed.), Addison-Wesley, 2001 D A Watt, Programming Language Concepts and Paradigms, Prentice Hall, 1990 J G P Barnes, Programming in Ada 95 (2nd ed.), Addison-Wesley, 1998 A Burns & A Wellings, Concurrency in Ada (2nd Ed), Cambridge UP, 1998 H Bal & D Grune, Programming Language Essentials, Addison-Wesley, 1994
A Barnes, 2005
1
CS2130/Ilect 1
Notes In addition to the reading list it may be necessary to consult text-books or programming manuals for other languages (particularly Ada, Java and C/C++). There will be one continuous assessment exercise distributed in towards the end of term 2 and handed in during term 3(dates to be confirmed). The exact form of the continuous assessment remains to be decided, but it is likely to be an individual programming exercise(s) in Ada (and possibly Java). Students will be informed in due course of the arrangements. A number of exercises will be set throughout the course. Completion and submission of most of these exercises will not be required and will not be formally assessed. However they form an integral part of the course and you are strongly advised to complete these. Some of the exercises will form the basis of examination questions and other exercises need to be mastered in order to understand material later in the module. Students resitting the module with attendance should note that the module content has changed slightly from last year. Students resitting the module with attendance will be required to complete the continuous assessment even if their CA mark at the first attempt was satisfactory. There will be no formal tutorials or problem classes for this module. However there will be a number of practical (lab) classes in MB473 You will be split into four smaller groups for these lab classes. Owing to staff shortages the lab classes will be fortnightly with two groups having classes in odd numbered weeks and the other two groups in even numbered weeks. Labs will start in the second week of teaching period 2 (week 3 of term 2). If you have questions about the module I will be available in the scheduled lab periods (whether or not your class is scheduled for that week) and in my office from 16.00-17.00 on Monday afternoons. I will NOT be available at other times except by prior email appointment (Email: [e-mail]). I will from time to time send email containing information relevant to this module to the mailing-lists for students enrolled on the course
seas_uscos_2
(BSc Computing Science Year 2)
It is your responsibility to look at your email regularly each week. Note that email will not be sent to individual student email accounts at (say) hotmail.com or other ISP's. Spare copies of the lecture hand-outs, problem sheets etc. will be placed on the table outside my office (MB212B). If you miss a lecture then you should collect ONE copy from there. Please do not collect multiple copies at lectures for 'absent friends'. A sufficient number of hand-outs will be duplicated for everyone registered for the module, when these are exhausted no more will be duplicated. Copies of the hand-outs will be available on-line in MS-Word format and PDF in the following location:
http://student.cs.aston.ac.uk/proginfo/modules/cs2xxx/cs2130/
or in meaningfully named links from the above. The simplest way to reach this site is by following the CS2130 link from my home page:
http://www.cs.aston.ac.uk/~barnesa//
(or following the links Programme Information --> CS2130 from the CS Student Intranet Home page
http://student.cs.aston.ac.uk/
Other material (example programs and some exercise solutions etc.) will be placed in the same locations from time to time. As mistakes and omissions in the notes are detected correction and addendum sheets will be circulated and the on-line versions will be updated.
A Barnes, 2005
2
CS2130/Ilect 1
Students who miss lectures for a substantial period through illness or other good cause should inform the CS office or their year tutor of their absence (you should do this as a matter of course anyway). If I am informed of this absence in good time I will endeavour to save a copy of the hand-outs for the student concerned. Reasons for Studying Concepts of Programming Languages Increased capacity to express programming ideas. If a programmer's vocabulary and knowledge of programming concepts is rudimentary and lacking in depth of abstraction, then that programmer will be limited in the form of control structures and data structures that they can use. It is difficult to conceptualise programming various constructs unless one has the means to describe them verbally and/or in writing. Also the ability to read and understand technical language manuals or programs written by other (better educated) programmers will be hampered. Even if a particular language does not support a particular construct directly, knowledge of the construct in another language and its advantages may motivate a programmer to simulate the construct (and so enjoy (at least some of) its benefits. Increased ability to learn new programming languages The time taken to learn a new programming language and use it effectively can be substantially reduced if one is aware of similar constructs and concepts in other languages that one already knows. If one has a good theoretical grounding and understands the advantages and disadvantages of certain constructs, then potential pitfalls and misunderstandings can often be avoided. Improved background for choosing a programming language. Knowledge of the strengths and weaknesses of available programming languages can aid in the choice of the most appropriate language for a particular programming project. Different languages may be appropriate for different types of project (Ada for safety critical applications, Java for Web-based programming, a scripting language such as Python for rapid prototyping. Better understanding of the significance of implementation. Sometimes the seemingly arbitrary limitations of a particular programming language construct can be traced to a difficulty in an efficient implementation of the construct in its full generality. Increased ability to design good quality new languages. For example avoiding designing new languages with some of the well-known shortcomings of existing languages when there are equally simple constructs without these problems. Overall advancement of computing and an improvement in the quality of software. Traditionally the most popular languages have not always been the best languages available for the software development process. Requirements of a Programming Language In this course we will only consider high-level programming languages, that is languages which are (more or less) machine independent. Hence we will not consider assembly language programming. A programming language should be universal, that is every problem capable of solution must have a solution expressible in that language. This is not such a formidable requirement as any algorithm can be expressed in terms of a very small set of control structures: namely sequencing, selection with IF and iteration with WHILE (Bhm and Jacopini, 1966)1 . Other programming constructs (CASE, FOR, functions and procedures, packages etc.) may be more convenient and/or lead to better quality (more robust) code but they are not strictly necessary
1
Bhm, C and Jacopini, G. Communications of the ACM 9, 36671 (1966). 3
CS2130/Ilect 1
A Barnes, 2005
A programming language should be reasonably natural for problem solving at least in the area for which it is designed. A language whose only data types are numbers (integers and reals) and arrays might be fine for 'number-crunching' application but would not be natural for (say) text processing A programming language must be implementable on a computer. Mathematical notation in its full generality is not implementable; as the work of Post and Turing showed there are functions one can define rigorously in mathematical notation which are not computable by a terminating algorithmic scheme. A programming language must be implementable on a computer in a reasonably efficient manner. Difficulties in implementation of languages such as Algol 68 and Ada 83 and hence the lack of availability of good quality compilers at a reasonable cost meant that they did not become as popular as simpler languages such as C and Pascal although arguably they were more powerful, better structured languages. Of...