sbloch@adelphi.edu http://www.adelphi.edu/sbloch/ http://www.adelphi.edu/sbloch/class/270/
August 31, 2011
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.
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).
Some computer scientists consider this four-paradigm framework too inflexible, arguing that a truly powerful language should enable the programmer to mix seamlessly individual features associated with each of the four.
A programming language is a tool. A programmer who approaches every problem by thinking about how to solve it in procedural/OO Java 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 a competent programmer must also 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 Java, Scheme, Ruby, 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).
(In the interest of accuracy, we’ll actually be using a variant of Scheme named Racket. And I’ll be learning Ruby right along with you....)
You can learn a lot more about cars by building or repairing one than by driving one. Similarly, you can learn a lot more about a programming language by implementing (part of) it than by just programming in it. This course doesn’t aim to make you a compiler-writer, but we’ll do just enough implementation to give you a glimpse “under the hood”; those of you who take CSC 272 next semester will go much more thoroughly into how a programming language works.
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.
If you already know how to program,
you can learn most of the basic syntax of the Scheme or Racket language in an
hour (see, for example,
http://home.adelphi.edu/sbloch/class/160/language/grammar.html).
You’ll still need to look up predefined library functions,
for which I recommend the "Help Desk" built into DrRacket.
If you really want a textbook, I can recommend a few “how to program”
textbooks that happen to use a language closely related to Scheme; you
should be able to skim quickly through the programming material that you
already know.
Bloch, Stephen, Picturing Programs, available on-line for
free from
http://www.picturingprograms.org
Felleisen, Matthias et al, How to Design Programs,
obsolete
first edition available on-line for free from http://www.htdp.org
and incomplete second edition at
http://www.ccs.neu.edu/home/matthias/HtDP2e
Shriram Krishnamurthi’s Programming Languages: Application
and Interpretation. This is intended as a textbook on programming
language implementation, for upper-level undergraduate or beginning
graduate students. We’ll do only a few chapters of it this semester,
and more next semester in CSC 272. This book, too, is free
on-line (unless you want a printed copy) at
http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/.
A Prolog tutorial at
http://www.amzi.com/AdventureInProlog/.
Also free on-line.
Online tutorials and manuals for Ruby; start at
http://www.ruby-lang.org.
If you're a member of ACM, you can also use the Ruby Learning Path at
http://learning.acm.org/path/ruby/index.cfm.
We’ll spend a few weeks on each of three specific languages: Scheme/Racket, Ruby, and Prolog. (Most of the students in this class are already familiar with Java, and although there are more advanced Java topics we could cover, I don’t want to spend class time on it.)
In the meantime, each of you will research another modern programming language, not covered in class, and in the last two weeks of the semester you’ll present what you’ve learned about that language to the rest of the class in a 20-30-minute presentation. Also turn in your presentation (whether PowerPoint or just notes), along with any other written supporting materials you’ve developed. The emphasis should be on what makes this language distinctive, what it’s particularly good at (and not so good at), and in what contexts one might want to use it. Include at least one correct, working program that you’ve written in the language. Some possible choices are (in alphabetical order) Alice, BYOB, Clojure, Eiffel, Erlang, F#, Go, Haskell, Lua, Matlab, OCamL, Oz, PHP, Processing, Python, R, and Scala; feel free to suggest others, but please choose a language you don’t already know. Discuss your choice with me in the first two weeks of the semester, so we don’t get several people presenting the same language; give me a progress report three weeks later.
I’ll give eight specific programming assignments, one every week or two: three in Scheme, three in Ruby, and two in Prolog. In addition, there will be three interpreter implementation projects: I recommend doing these in PLAI Racket, since that’s the language used by the Programming Languages: Application and Interpretation textbook (and because these assignments are much easier to do in Racket: one year I translated a student’s work into Java, and gave up when the first 40 lines of Racket had turned into 700 lines of Java.)
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 or how to express your solution in a new language. When you turn in a program with two students’ names on it, I want each of the students individually to also send me a brief description (a paragraph or so) of how the team worked and what you think each partner contributed and learned.
You’ll learn something different from each classmate you work with, so you are encouraged to switch partners from one program to another.
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. So....
Each of eight homework assignments will be worth 5% of the semester grade. Each of three implementation projects will be worth 10% of the semester grade. The language presentation will be worth 10% of the semester grade. The final exam will be worth 10% of the semester grade. The remaining 10% of the semester grade is “brownie points”: did you ask good questions in class, answer questions in class, contribute constructively to on-line and classroom discussions, work well with your partners, etc?
Any program turned in after midnight, Friday, Dec. 9 will be thrown away ungraded.
We’ll have a two-hour final exam on Dec. 15, from 10:30 AM to 12:30 PM. The final exam is comprehensive: it may include questions about any of the three languages or Java, about programming languages in general, about implementation issues, about the language you researched on your own, or about which language you would choose 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. Exams not taken without one of the above excuses will be recorded with a grade of 0.
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 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 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.
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 2020.