Computer Science 270 Survey of Programming Languages TTh 9:25–10:40 AM

Dr. Stephen Bloch office 112 Alumnæ Hall phone 877-4483

                email sbloch@boethius.adelphi.edu

office hours: whenever I’m not teaching on Tuesday, Wednesday, and Thursday

September 17, 1996

1 Prerequisites

Students taking this course are expected to have successfully completed CSC 171 (“Introduction to Structured Programming with Pascal”) and CSC 172 (“Introduction to Algorithms and Data Structures”). This is largely a programming course, so students should expect to spend a lot of time designing, writing, testing, and debugging programs. If you don’t meet these prerequisites and aren’t already a hot-shot hacker, I strongly urge you not to take this course.

2 Subject Matter

If you’re taking this course, you are already comfortable with the notion of writing a program, and you’ve learned some of the techniques and data structures most often used in computer programs, especially Pascal programs. But Pascal is only one of literally hundreds of computer languages, each with its own strengths and weaknesses. A programmer who approaches every problem thinking about how to solve it in Pascal is like a carpenter who uses a hammer on everything, even when a saw or a screwdriver would be more appropriate. A competent programmer must be able to select the most appropriate language for any given problem. Furthermore, a competent programmer must be able to write idiomatically in each language, i.e, to write in the style to which that language is suited: don’t be like a carpenter who chooses a screwdriver as the appropriate tool, but still uses it like a hammer. Finally, a competent programmer must be able to learn a new language and its idiom quickly.

We’ll spend the first half of the semester learning the C language. C is similar in many ways to Pascal, but it differs both in superficial ways, like where to put semicolons, and the use of braces rather than begin and end, and in more significant ways, like the relationship between pointers and arrays. C is also the most commonly used language in connection with the Unix tm operating system, which most of you are studying concurrently in CSC 271. C is also a good introduction to C++, a more powerful (and more complex) language which has become very popular among commercial software developers. We’ll also work with the gdb debugger, an immensely valuable program that helps you see where your C programs are going wrong and how to fix them.

After the midterm, we’ll switch to a very different language named Scheme. Scheme is a modern dialect of one of the oldest computer languages, Lisp, which was originally written not to deal with numbers and characters, but to deal with symbols, lists, and the process of computation itself. In the 1960’s and ’70’s Lisp developed a reputation as a good language for artificial intelligence programming. In the past decade Lisp and Scheme have become increasingly popular as teaching languages, both for serious computer science students and for non-CS students who want to understand what computers can and cannot do. Scheme requires completely different ways of thinking about programming: some of the problems you worked hard to solve in C are trivial in Scheme, while other problems you wouldn’t have even thought of from a C mindset become serious and reasonable questions in Scheme.

3 Textbook

For the C portion of the course, we’ll use the book C by Dissection: the essentials of C programming, by Al Kelley and Ira Pohl, 3rd edition. (The 2nd edition, used for this course last year, contains most of the same material, but some sections have been added and some explanations rewritten.) I expect you to read the first 10 chapters of this textbook in the first 9 weeks of the semester, which means an average of about fifty pages a week.

I haven’t found a really suitable textbook for teaching Scheme at this level, so the Scheme portion of the course will rely more on lectures and exercises.

You are responsible for everything in the reading assignments, whether or not I discuss it in a lecture.

4 Grading

As I write this (a few weeks before classes start), I envision five homework assignments, each worth 10% of the semester grade, a midterm worth 20%, and a final exam worth 30%. I may change this somewhat as the semester unfolds.

Exams must be taken at the scheduled time, unless arranged in advance or prevented by a documented medical or family emergency. If you have three or more exams scheduled on the same date, or a religious holiday that conflicts with an exam or assignment due date, please notify me in writing within the first two weeks of the semester in order to receive due consideration. Exams not taken without one of the above excuses will be recorded with a grade of 0.

Homework and programming assignments will be accepted late, with a penalty of 1/3 per 24 hours or portion thereof after they’re due. An hour late is 33% off, 25 hours late is 67% off, and after 48 hours don’t bother turning it in. It’s still a good idea to do as much of it as you can, however, because I’ll assume on the exams that you’ve done the homework.

Programs are not abstract works of art, they are supposed to run and solve real problems. So if I get a program that doesn’t compile or run, or a program that has little or nothing to do with the problem I assigned, I will give it a zero, no matter how much time you put into it. Don’t bother turning in a program you haven’t tested yourself.

5 Ethics

Most of the assignments in this class are to be done individually. You may discuss general approaches to a problem with classmates, but you may not copy large pieces of programs or homework solutions. If you do, all the students involved will be penalized.

All work on an exam must be entirely the work of the one person whose name is at the top of the page. If I have evidence that one student copied from another on an exam, both students will be penalized; see above.

6 Schedule

This class meets every Tuesday and Thursday from 9:25 to 10:40 AM, except on University holidays or if I cancel class. All dates in the following schedule are tentative, except those fixed by the University; if some topic listed here as taking one lecture in fact takes two lectures to cover adequately, or vice versa, the schedule will shift.

I expect you to have read the specified chapters in the textbook before the lecture that deals with that topic; this way I can concentrate my time on answering questions and clarifying subtle or difficult points in the textbook, rather than on reading the textbook to you, which will bore both of us. Please read the textbook!

Date(s) Assignment Reading Lecture Subject 5 Sept Administrivia, accounts, passwords, introduction

10 Sept  1  Writing, compiling, and running C programs in Unix tm
12 Sept  HW1  info gdb Debugging in Unix tm
17 Sept  2  Language structure: lexical elements

19 Sept Using C operators 20 Sept Last day to add courses 24 Sept 3 Language structure: control flow statements 26 Sept Using loops, conditionals, etc.

1 Oct  HW1 due 4  Functions in C
3 Oct  HW2  Structured program design

4 Oct Last day to drop courses

8 Oct  5  Characters in C
10 Oct  6  Other basic data types in C

15 Oct Using primitive data types

17 Oct  HW2 due 8  Pointers and storage in C
22 Oct  HW3  Using pointers and different storage classes
24 Oct  9  Arrays and pointers in C
29 Oct  10  Strings and pointers in C
31 Oct  7  Inventing new types in C

5 Nov Catch up and review for midterm 7 Nov Midterm exam 8 Nov Last day to withdraw from classes 12 Nov HW3 due Discuss midterm; introduction to Scheme 14 Nov The read-eval-print loop, quote, atoms, functions 19 Nov Lists, assembly and disassembly of 21 Nov HW4 Defining new functions 26 Nov Variables, define, and set! 28 Nov Thanksgiving — no classes

3 Dec  HW5  Recursive programming to manipulate lists
5 Dec  HW4 due  More on recursion and list manipulation

10 Dec Code as data and data as code 12 Dec HW5 due Catch up and review for final 19 Dec 10:30 AM–12:30 PM, Final Exam