|
|
Here is what the ORC has to say about COSC 8:
Motivated by applications in the arts, sciences, social sciences, and computer systems, this course develops skills in solving problems computationally. Topics covered include representation (how to capture computationally the objects and processes of a problem), abstraction (how to build high-level, multi-purpose toolkits for manipulating representations), recursion and modularity (how to break problems into subproblems and combine the solutions), reasoning (how to understand what a computation is doing), and concurrency (how to deal with multiple simultaneous processes). These concepts are taught within a functional programming language that supports them well; they are applied in a series of programming labs solving fun application problems.
Prerequisite: Computer Science 5, or placement in
Computer Science 8 via Advanced Placement or departmental exam.
Dist: TLA.
Now that you've got some programming experience, let's use it to do some fun stuff! We'll construct animations, analyze biological sequences, search social networks, play games, parse and manipulate HTML, identify clusters in data sets, solve puzzles like Sudoku, and more. And, while we're doing that, we'll also develop expertise in core programming techniques useful throughout computer science. We'll use a language called Haskell, which makes it easy to quickly and incrementally develop solutions to these problems, while really making clear (and enforcing) the underlying core concepts.
You know how to program in one paradigm, which is an object-oriented procedural paradigm. Assignment statements, loops, and the ideas of sequential processing are basic building blocks. In the functional paradigm the emphasis is different. Recursion and functions come to the fore, especially higher-order functions (functions that take functions as arguments and/or return functions as values!). At first this approach may seem weird, but as you get into the course you should come to appreciate its power to allow you to abstract and to think about and express your programs at a higher level. The programs that you write in Haskell will usually be much shorter than equivalent programs in Java. We will often be able to do in a line or two what would take half a page or so in a procedural language.
This is not, however, a course about the Haskell language! Haskell just happens to be the notation that we have chosen for writing programs. The major goals of the course are to develop your skills and vocabulary for reasoning clearly about programs and programming, and to provide a toolbox of modern programming techniques that will be applicable in almost any language.
Our regular lectures will be held in 006 Kemeny Hall during the 11 hour, which is 11:15-12:20 each Monday, Wednesday, and Friday. We will be using about half of the X-hours, which is 12:00-12:50pm each Tuesday, for exam review, to make up for cancelled classes (Martin Luther King day, Winter Carnival), or other activities throughout the term. Please do not schedule anything else during that time. I will post changes on the Syllabus page and will send email.
We will also have weekly sectional meetings with section leaders on Thursdays. These sessions will review topics covered in class and provide additional examples, discuss approaches to the homework problems, and give you a time to ask questions in a setting with fewer than 10 students.
In order to schedule sections, please send an email to Shaohan Hu saying which of the following times on Thursdays you can meet for 50 minutes. (Note I am not asking you to pick your favorite time, although you may note that and we will try to honor it. I am asking for all times that don't conflict with other commitments.)
Scot Drysdale, 248 Sudikoff
Gabriel Weaver, 142 Sudikoff
Shaohan Hu, 255 Sudikoff
There will be a course staff member present in either Room 002 or Room 003 Sudikoff from 8:00-11:00pm on most Sundays, Mondays, Tuesdays, and Thursdays throughout the term. Exceptions will be posted under Announcements.
Getting Help via email: cs8@cs.dartmouth.edu mails to the entire course staff, and the first one to see it will try to answer your question.
There is one required textbook for this course:
The Haskell School of Expression:
Learning Functional Programming Through Multimedia,
by Paul Hudak.
ISBN 0-521-64408-9, published by Cambridge University Press.
This text should be available both at The Dartmouth Bookstore and at Wheelock Books; it can also be ordered online.
Unfortunately, this book has a number of typos, some of which can be quite confusing. Fortuantely, there is an errata page. I strongly urge going to erata.htm and making the corrections in your book. It will reduce confusion later.
There will also be course handouts and lecture notes, available online. The final, definitive version of all course materials is the course web site. You are responsible for checking the web site for updates and corrections.
The Haskell compiler that we will be using is the Glasgow Haskell Compiler (GHC), developed by a team of programmers at the University of Glasgow. Versions of GHC are available for Macintosh, Windows, and Unix systems, so you can use the compiler on whatever kind of machine you happen to possess. We will generally be using it in its interactive interpreter mode (GCHI), but it is also possible to use it to compile stand-alone applications.
On top of GCH, we will be using the SOE Graphics package developed for our textbook. (It is a stable subset of a larger graphics package for Haskell.)
See the course software page for information and instructions on how to download and install the course software.
Students are responsible for all material in the assigned readings, as well as material covered in lectures. There will be seven problem sets (homework assignments), about a dozen short assignments, a midterm exam, and a final examination. Homework assignments will generally be due on Wednesdays. Each problem set may include written exercises as well as a programming assignment. Course grades will be based on:
You should try to complete programming assignments early, as late work is heavily penalized (see below). The best strategy is to begin reading over the assignment as soon as possible after it is is made available, so you will know what you are getting into.
As with any programming task, the best policy is to "think twice, code once." In other words, think about the problems before typing anything at the computer. Also, don't be afraid to back up and start over if you find you're stuck in a bad solution! It often takes less time to start again, and you can always keep copies of your old solution in case you change your mind. This is particularly true in Haskell. Solutions to short assignments will often be a few lines of code, and solutions to problem sets will usually be a page or a few pages of code. It takes very little time to type the solutions. Deciding what to type is the difficult part.
No matter how many times we give this advice, it seems to take a long time to sink in. Think before coding!
All of the assignments in this course consist of some combination of written exercises and programming exercises. Unless specifically overridden, all assignments are due according to the following rules:
Unless prior arrangements have been made, or in case of medical or family emergencies, or specific disabilities, all assignments are subject to the following policy regarding late submissions:
For all assignments, you must turn in a hard copy listing of any text, code, or diagrams you wrote or modified for the assignment.
In addition, unless otherwise specified, you must also submit a machine-readable electronic copy of any code you wrote or modified for the assignment. Specific instructions for electronic submission are included with each assignment.
Part of learning the discipline of programming is learning how to show that your programs behave as they are designed to do. There are four important strategies for doing this:
All the code you submit for this course must be accompanied by some combination of these items sufficient to demonstrate that it works, in order to receive credit.
Documentation may consist of comments in the code itself that explain how your algorithm works, what its constraints are, and any other relevant insights. Testing consists of choosing a set of interesting and relevant test cases, and showing that your programs can correctly process them. Formal proofs are one of the topics of this course, and will be discussed in more depth during the term.
For some problems, we will provide you with specific test cases that you may try; however, whether or not test cases are provided, you are expected to fully demonstrate that your programs work as specified, using some combination of the above tools.
If you turn in code without demonstrating its correctness, you may receive no credit.
Problem sets are detailed programming assignments that challenge you to use the ideas we study in lecture to solve new problems. You will generally have a week or more to complete a problem set, and the results are graded on correctness, structure, style, and testing.
Correctness describes the degree to which your solution correctly solves the assigned problems. Structure measures how well-organized and logical your code is, and how well it takes advantage of the Haskell features and programming techniques that you are learning. When appropriate it will consider the efficiency of your algorithms. Style measures the readability of your code and the clarity of your comments and documentation. Testing measures how convincingly you demonstrated that your solution is correct.
Grading rubrics will be linked to the problem description, so that you can see what each part is worth.
Short assignments are designed to provide practice and feedback to aid your understanding of the course material. The possible grades for a short assignment are 0, 1, or 2. A grade of 2 means your solution is correct and good. A 1 indicates that your solution needs work. A 0 is given if nothing of substance is turned in.
If you receive a 1 on a short assignment, you may, at your option, re-work your solution and resubmit it to be re-graded. If your resubmitted short assignment receives a 2, that grade replaces your 1. You may only resubmit once for a given short assignment, and resubmissions must be received no later than the first regular class period after the original result was handed back to the class, whether or not you attended class on the day the result was handed back. Please attach the original graded assignment to the resubmitted version.
Only short assignments may be resubmitted in this way. Regular problem sets and exams will only be graded once. Note, however, that this policy does not apply to errors in grading. If you suspect we have made a mistake in the grading of any assignment or examination, you may (and should) bring it to our attention promptly -- fixing grading errors does not count as resubmission!
Throughout the term, there will be opportunities to earn points of extra credit. Some problem sets have specific extra-credit problems. You may suggest other extensions for extra credit, and if I agree that the work is worthy of extra credit it will be awarded. Furthermore, any exceptionally clever, creative, or insightful work may be awarded extra credit points.
As its name suggests, extra credit is always optional, and you should never feel that you have to do extra credit problems. Extra credit points are recorded separately from other grades. When assigning grades at the end of the term, some people are on the borderline between two grades. If you are in such a situation, extra credit work is a good reason for giving you the higher grade. Extra credit can also lead to a citation.
Extra credit points can only help, never hurt, your final grade, regardless how much or how little extra credit you or your classmates choose to do.
You should not view extra credit as a substitute for doing good and thorough work on your assignments! Extra credit is no substitute for keeping up with the main work of the course. On the other hand, for those who become excited by some of the new ideas we'll explore in this course, and wish to explore beyond the boundaries, I intend extra credit to serve as a means to recognize your exceptional effort.
Much of the learning in this course comes from doing the programming exercises. On many problem sets, you may work jointly with one (1) other person, if so stated. No more than two people may work together on a given problem set. If you choose to work with someone else, the following rules apply:
On short assignments, you must work alone unless otherwise stated in the assignment.
Under no circumstances may you hand in work done with (or by) someone else under your own name. If you have any doubt, credit any person(s) (other than course staff) from whom you got help. Your code should never be shared with anyone, other than your partner (if you are working in a pair).
Any hard-copy or electronic sources used must be properly cited and acknowledged. The only exceptions to this rule are as follows:
However, you may not consult any solutions from previous terms' CS 8 assignments or CS 18 assignments, whether they are from faculty or other students. (CS 18 is an earlier version of CS 8.) You may not look at exams from previous offerings of CS 8 or CS 18, except for ones that we distribute as sample exams.
We take the Honor Code very seriously, so please, if you are unclear on any matter regarding this policy, do not hesitate to see me in office hours, and I will be more than happy to answer your questions. It is always best to provide proper citations. Please ask first, if you are unsure!
Dartmouth provides public Macintosh, Linux, and PC facilities. You may use your own personal computer, or the public ones, at your option. Since the course software is available for a wide variety of operating system and hardware combinations, it doesn't really matter which platform you use. The computer science department provides computer facilities in Sudikoff for this course.
To get access to the laboratories, download and fill out the Sudikoff Access Form on the CS internal website: http://www.cs.dartmouth.edu/internal/ and follow the directions on the form.
You are entitled to use the computer laboratories in rooms 001 (Linux), 002 (Displays for laptops), 003 (Macs that dual boot Windows), or 005 (Macintosh) in Sudikoff. All computers in these labs will have the course software loaded on them.
You can make use of any of these machines for the course. We will not be teaching you how to use Unix in this course, apart from the basics needed to get around on the lab machines and Terminal window. A good start is the following Basic Unix Guide. However, you will probably find it quite useful to explore a bit further, especially if you intend to pursue further work in computer science.
In order to use the Windows and Linux machines in Sudikoff, you will need a login account. If you do not already have one, and would like to, contact Gabe Weaver with a two or three choices for your preferred login-name, as soon as possible (keep in mind that login names are limited to 8 characters, and must begin with a letter).
Keep in mind that it might take a day to get your account created, so please don't leave this 'til the night before a problem set is due, if you intend to use the lab machines! Macintoshes do not require logins.
There will be seven problem sets. Problem sets are intensive exercises to build your programming skills and strengthen your understanding of the lecture material. You will have at least a week to do each problem set.
There will also be about a dozen short assignments given throughout the term. These are simple exercises to help you get familiar with basic concepts, and to provide you feedback on your understanding. Short assignments are generally due at the next lecture after they are assigned.
See the Course Materials page for a schedule of problem set assignments and due dates.
These dates are unlikely to change, although it is possible that the locations will.
| Exam | Date/Time | Location | |
|---|---|---|---|
| Midterm | Thurs. Feb. 5, 2009, 7:00-10:00pm | Moore B03 | |
| Final Exam | Sat. Mar. 14, 2009, 8:00-11:00am | Kemeny 006 |
CS 8 was developed at Dartmouth College by Scot Drysdale and Chris Bailey-Kellogg, with substantial assistance from Michael J. Fromberger in the summer and fall of 2007. It replaces CS 18, a similar course using Scheme that was based on 6.001, developed by Gerry Sussman and Hal Abelson in the EECS Department at Massachusetts Institute of Technology (MIT). Bruce Donald developed CS 18 at Dartmouth.
The course web site is built on one written by Michael J. Fromberger using only 100% recycled fair-trade nonrecombinant organically home-grown binary digits, with help from Linux and Mac OS X.
Home Page |
Announcements |
Materials |
Software |
Department of Computer Science, Dartmouth College, Hanover, New Hampshire, USA
Last modified: 12-January-2009