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 -- on the order of five hours/week outside class -- designing, writing, testing, and debugging programs.
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).
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
read and write correct, working, idiomatic programs of a few dozen to a few hundred lines in C++, Scheme, and Prolog, using a variety of data and control structures;
explain differences and similarities among the procedural/imperative, object-oriented, functional, and logical programming paradigms;
upon seeing a programming assignment, assess the advantages and disadvantages of solving it in various languages and paradigms, and choose an appropriate language and paradigm to solve it;
learn a new language quickly upon demand (e.g. by an employer who needs you to write in that language).
Goethe once wrote "he who doesn't know foreign languages knows nothing of his own." (Of course, he wrote it in German: "wer fremde Sprachen nicht kennt, weiß nichts von seiner eigenen.") 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.
I've ordered a textbook through the Bookstore, and included links to some other on-line sources:
Bjarne Stroustrup's The C++ Programming Language. Stroustrup invented C++, almost single-handedly, in the early 1980's, and his book is still the definitive reference on it. He also included a lot of good advice on object-oriented programming and design.
An on-line textbook for beginning programming, which happens to
use Scheme, at http://www.htdp.org.
The precise coverage of this course changes from year to year, depending on how many students have what background. This year, some of you have studied C++, all have studied Java, a few Scheme, 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 of programming languages, followed by a few weeks on each of three specific languages: 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 week 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, Wednesday, Dec. 5 (the last day of class) will earn only partial credit; any program turned in after midnight, Wednesday, Dec. 12 will not be graded (so I have time to finish grading programs before the final exam on the 17th).
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:
Every program must contain, in the first few lines, a comment indicating the name of the student 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.
The Adelphi University Code of Ethics applies to this course; look it up on
the Web at http://academics.adelphi.edu/policies/ethics.php .
Most homework assignments in this course involve writing, testing, and debugging a program by yourself 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 . If I see that three different people 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.
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.