Computer Science 270
Survey of Programming Languages

Dr. Stephen Bloch
office 113A Alumnæ Hall
phone 877-4483
Web page
Class Web page
office hours M 11:00-2:00, W 10:00-1:00, TTh 3:00-4:00
class meetings TTh 9:25-10:40 AM

August 22, 2006

1  Who Should Take This Course

This course is intended primarily for students majoring or minoring in computer science or information systems. It assumes CSC 171 and 172 as prerequisites. If you're taking 172 concurrently with 270, you'll have a more difficult time, but you should be able to survive the course; talk to the instructor. This is largely a programming course, so students should expect to spend a lot of time designing, writing, testing, and debugging programs.

2  Languages and Paradigms

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. But you've probably only worked in one or two languages (e.g. Scheme, Java, C++, C, Visual Basic, Perl, PHP, Python...), of the thousands of languages out there, each of which has its own strengths and weaknesses.

The word "paradigm" originally meant a way of remembering verb conjugations and noun declensions. Since the publication of Kuhn's Structure of Scientific Revolutions, the word has taken on a different meaning: an approach to a field of study that affects not only what answers you get, but even what questions you ask.

Computer scientists often refer to four major paradigms of programming: procedural or imperative, object-oriented, functional, and logical or declarative. But the boundaries aren't always clear-cut. It's generally possible to program in any paradigm in any language; languages differ in what paradigm "comes naturally". Thus we describe Scheme as a "functional language", C a "procedural language", and Prolog a "logical/declarative language" because those are the paradigms that come most naturally in each language. C++ and Java are both on the spectrum between procedural and object-oriented, with C++ more procedural and Java more object-oriented. Each paradigm works best to solve a particular sort of problem, and to be a competent programmer you should be familiar with all four (and whatever fifth one comes along in a few years).

3  What You Should Expect to Get from This Course

A programming language is a tool. A programmer who approaches every problem by thinking about how to solve it in procedural/OO Java or C++ 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 and paradigm for any given problem. (Half of last year's final exam in this course was "For each of the following programming problems, what language would you use to solve it and why?") 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 the carpenter who chooses a screwdriver, but still uses it like a hammer. And finally, a competent programmer must be able to learn a new language and its idiom quickly.

So by the end of this semester, you should be able to

Goethe once wrote "he who doesn't know foreign languages knows nothing of his own." It's hard to understand the structure of a language if you don't have other languages to compare it with. The same goes for programming languages: even if you end up writing most of your future programs in Java, the experience of having written in other languages and other paradigms may make you a better Java programmer.

4  Texts

I've ordered two textbooks through the Bookstore, and included links to some other on-line sources:

5  Topics and assignments

The precise coverage of this course changes from year to year, depending on how many students have what background. This year, a few of you have studied C++, most have studied Java, a few Scheme, one or two C, and probably none have studied Prolog. I'd like you to concentrate your efforts on languages you don't already know, and secondarily on advanced features you don't already know of familiar languages.

We'll spend the first week or two discussing the history and theory of programming languages, followed by a few weeks on each of four specific languages: C, C++, Scheme, and Prolog. (We won't spend much class time on Java; if you're not solid on Java, talk to me and we'll arrange things to meet your needs.) The last two weeks of the semester will be largely "supervised lab time" for you to work on programs, particularly in whatever languages are the most unfamiliar to you.

Throughout the semester, I'd like you to select and write programs on a self-paced basis (I'll provide a list of suggestions, but you're not required to do all of them, and you're welcome to do assignments not on my list) to demonstrate your abilities in each language. In many cases, you'll find it helpful to write programs in several different languages and paradigms to solve the same problem, so you can compare them side by side.

You may turn in as many or as few programs as you wish, as long as they are your own work. You may even turn in a program you are also turning in for credit in another course; I'll grade it on your use of the language, which is probably not the central concern in the other course.

However, I don't promise to read more than one program per student per week, so if you turn everything in at the end of the semester, I'll probably read the shortest program, and throw away the rest. Any program turned in after midnight, Thursday, Dec. 14 will earn only partial credit; any program turned in after midnight, Sunday, Dec. 17 will not be graded (so I have time to finish grading other programs before the final exam on the 21st).

You are encouraged to write some or all of your programs using "Pair Programming", a common professional practice in which two programmers work together to design, code, test, and debug the program. I'll give you some articles about Pair Programming, but I want to point out that it does not mean "you write one program, I'll write another and we'll both get credit for both;" it means both students work together on all of the program, taking turns having one type while the other looks over the typist's shoulder. The main benefit of this, particularly when you're working in an unfamiliar language, is that the one who's not typing can continually proofread for typoes, syntax and logic errors, and you can brainstorm together on how to solve the problem. Furthermore, if the two of you have different language backgrounds, you can help one another understand how to express things in various languages --- as long as you both understand it by the end. You'll learn something different from each classmate you work with, so you are encouraged to switch partners from one program to another.

6  Grading

The most important part of my job in this course is to help you develop an understanding of how and why to program in different languages and paradigms. The less important and less fun part is assigning a letter grade at the end of the semester. Obviously, a single letter grade won't capture everything you've learned and what you can do that you couldn't do before, but Adelphi and the State of New York require it. Your semester grade will be based on several things:

Language-specific skills
This course, frankly, is about breadth more than depth. You'll learn parts of four or five different languages, each of which has dozens or hundreds of features and capabilities. So I've written up a list of skills I'd like you to master in each language. You'll choose programming assignments (either from a list I provide, or on your own) that demonstrate your mastery of various skills. Whenever you turn in a program, I'll go through each of the skills you've demonstrated in that program and assign a numeric score: These numbers will be multiplied by weighting factors: If you demonstrate a particular skill at different levels in different programs, I'll keep the highest score for that skill. (So if you've already demonstrated a particular skill in one program, the fact that the next program doesn't call for that skill won't hurt you.)
General programming skills
I've also written up a list of "language-independent skills", which in my opinion can and should be displayed in any language. I'll grade each of these on the same 0-3 scale as above, but the results will be averaged over all the programs you turn in.
Log or diary
I want you to keep a log or diary throughout the semester, and turn it in to me whenever you turn in a program. (A plain text file, or Word document, or Web page -- whatever format is comfortable for you, as long as I can read it. If you prefer paper, turn in a scan or photocopy so you can keep using it while I read and grade it.) Jot down difficulties you encounter with programming languages, with programs, with my lectures, and with programming partners. I particularly want to see your individual impressions of how Pair Programming is working: what did each partner bring to the project, what did each partner learn from the project, how did the partners work together in practice, etc. And I want to see how you think about and analyze problems.
Final exam
Two hours, from 10:30 AM to 12:30 PM on Dec. 21. The exam is comprehensive: it may include questions about any of the five languages, about programming languages in general, or about which language you would use (and why) to solve a particular problem. The final exam 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.
Brownie points
This is my purely subjective impression of how seriously you're taking this course. Did you ask and answer good questions in class? Did you help your classmates learn (without stepping over the line into "doing their work for them")? When you were confused, did you come to my office and ask me for help? Did you attend class and pay attention? Did you take the opportunity to learn new things and challenge yourself, or did you turn in a lot of programs that you could have written last year?

7  Program standards

Every program must contain, in the first few lines, a comment indicating the name(s) of the student(s) working on it and what the program is supposed to do. Programs not containing this information, clearly visible, will get a zero.

Every program must be accompanied by a session log (I'll show you how to do this) showing how the program works on test cases. Programs with inadequate or poorly-chosen test cases will lose points; programs turned in with no test runs at all will lose lots of points.

Every program must be adequately and accurately commented, as appropriate in the current language.

For those of you who used PSP in CSC 160, 171, or 172, I've set it up (and improved it somewhat) for this class's use too. You are invited to use it to record your time, program size, and defects encountered, but I don't plan to grade it this semester.

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

8  Ethics

The Adelphi University Code of Ethics applies to this course; look it up on the Web at .

Most homework assignments in this course involve writing, testing, and debugging a program by yourself or in a team of two. You are welcome to seek help on mechanical and syntactic matters ("how do I save this file?", "how do I get a session log?", "what does this compiler error message mean?") from other students in the class or from tutors in the Learning Center; however, for higher-level tasks of design, coding, testing, and debugging, I expect you to work by yourself or with your one partner. If I see that three different people/teams have turned in nearly-identical programs, I'll grade it once and divide the credit among the three, so the best any of them can hope for is 33%. If you turn in a program that I can find on the Web (without your name on it), it'll get a zero.

9  Conclusion

But cheating and copying aren't what I want to think about this semester. I find computer languages a fascinating subject, at the intersection of computer science and human psychology. Language designers are coming up with new neat ideas every day, which is one reason there's a new "hot" language every few years. Perhaps one of you will have an idea that becomes the "hot" language of the year 2015.

Last modified: Tuesday, August 22nd, 2006 1:14:30pm