198:314 Principles of Programming Languages
Fall 2007
Ryder's Lecture
Course Information
Read this document carefully! It will answer your questions about how to be successful in CS314. Also, check the main CS314 class webpage daily for important announcements.
The prerequisites for this course are 198:112 and 198:205 or their equivalents in the ECE curriculum. If you have not taken these courses, then you should drop this course--it's not for you. This course assumes that you know what's in the prerequisites, as well as what's in their prerequisites.
The primary goal of the course, and the one which will be addressed in lecture, is to have each student learn the key characteristics of programming languages, in order to facilitate life-long learning of new languages later in their computer science career. Thus we will learn which concepts and abstractions are common to all programming languages, and which differentiate them from one another. We will learn how to define a programming language, how properites of a programming language can help help to ensure correct programs, and a bit about how programming languges are translated and implemented.
A second goal, to be re-enforced by the programming projects, is to give students some exposure to several different programming language paradigms. This term we will do projects using Prolog, Scheme, and Python. There are IDEs and/or compilers available for many of these languages that run on PCs and/or Macs. For grading purposes, we will be running the language versions available on the undergraduate servers remus, romulus and rhea as our UNIX computing resource.
In addition, supplementary class materials will be placed on reserve at the SEC Reading Room (on the Busch Campus) during the term. We also have placed on reserve some reference books on each of the programming languages we will study in detail. The material can be found under the course number (198:314).
Required Textbook:
Michael L. Scott, Programming Language Semantics, Second
Edition, 2006.
Reference books:: R. Kent Dybvig, The Scheme Programming Language , Prentice-Hall, 1996. Note: This book is out of print, but there is an online version .
Recommended: Clocksin and Mellish,
Programming in Prolog, Fourth Edition, Springer Verlag, 1995.
a python book TBD
There will be a midterm and a final exam. Each exam will contain questions referring to knowledge gained from the programming projects and homeworks, as well as lectures. Therefore, if you do not do the projects, you will find it difficult to answer these questions. The final exam will cover the material for the whole course. All tests are closed book exams.
In emergency situations, when you are unable to get to the test or exam, it is your responsibility to contact your instructor or TA before the exam and notify them of the situation. Documentation of your emergency will be required! A call to the Dean's office can provide this. Alternate arrangements will be made for people with documented difficulties. ALL STUDENTS ARE EXPECTED TO TAKE THE EXAMS AT THEIR SCHEDULED TIME, UNLESS THEY HAVE NOTIFIED THEIR INSTRUCTOR AT LEAST A WEEK IN ADVANCE OF A UNIVERSITY-RECOGNIZED CONFLICT, AND ALTERNATE ARRANGEMENTS HAVE BEEN MADE .
There will be weekly written homework assignments and three programming projects. In order to pass the course, all programming projects must be completed and handed in. Projects that do not compile or have syntax errors will be given a grade of 0. We will not edit any of your programs or change program names as part of the grading process.
The non-programming homework assignments will be posted on the course website. No late submissions will be accepted. These will be handed in and discussed in recitation. Do this homework! It is intended to aid you in learning the material. We will use material from your homework on the tests.
The programming projects in this class will be graded on functionality, program design, proper use of programming paradigm, and programming style (e.g., comments, use of descriptive variable names). The test data we distribute with the assignment will not be comprehensive; instead it is meant to test minimal functionality of your code. It is your responsibility to test your programs more fully. For grading purposes, an automatic script will run your submitted program on new test data. The output from your program will be compared with the output from our answer on the same data. The UNIX diff command may be used to compare this output; therefore, the strings "abc" and "a b c" (with embedded blanks) will NOT COMPARE AS EQUAL. You must take care to format your answer as explained in each assignment. An email that explains your grade, in terms of the tests passed and failed by your code, will be automatically sent to you by the grading procedure.
Each project grading policy is designed to be as fair as possible. The instructor, not your TA is responsible for the policy; disagreements about grading policy (rather than grading mistakes) should be discussed with your instructor, not the TA.
Course grades will be based on your performance on the midterm, final exam, homeworks and projects and your participation in class and recitation. Exams will count for at least 50% of the final grade, with the additional proviso that in order to pass the course, the student needs to pass at least one exam. We consider recitation attendance mandatory for this course; your participation in recitation will count in your grade. We will take attendance both in recitation and in lecture.
Our tentative grade weights are: 250 points midterm, 350 points final exam, 300 points for the programming projects and 100 for written homeworks, recitation participation and attendance. We reserve the right to adjust these weights as necessary during the term.
Your achievement according to this weighting constitutes a raw score. A class curve will be used, but a set minimum number of points will be required in order to pass the course. We will post the test grades with medians, so that you have some idea of where you stand; remember, an average grade is C.
A fairly important consideration in passing this course is keeping up with your work. It doesn't pay to delay working on a programming project, because there's another project coming right behind it. By definition a late programming project is one which is handed in (electronically) after the time specified in the project statement. A late program will incur a penalty of 20% per school day or fraction thereof (you get weekends and holidays off). So if it's more than five days late, it's worth zero points; even so, the project must be completed and handed in.
It often happens that a student may miss a deadline because of some unavoidable circumstance, such as illness. Such latenesses are excusable, but only with documentation. After-the-fact excuses (e.g., ``My car broke down'') are not acceptable. Even ``I've been in bed with flu all week and couldn't get it done'' won't work, but a note from your Dean, verifying the mishap is acceptable. On the other hand, if we are told in advance that you won't be able to get something in on time for a valid reason, we can make appropriate arrangements for late hand-in.
Last updated at 11:42am on August 31, 2007 by BGR.