General Issues

• Syllabus
• Rules for writing programs

I will offer you advice on how to do things. Many of you will ignore this advice. When you do, you will have only yourself to blame when things work out badly for you. You have been warned.

Philosophy

This course requires looking both at low level details of programming (pointers and memory allocation, for example) and at high level organizational issues (abstract data types, for example). There are two competing philosophies on how to deal with this. Show how to create simple abstract data types, hiding all of the details, and later learn how to build more complex ones using pointers and memory management. Show how to create concrete data structures using pointers and memory management, using an approach that does not hide details, and later show how to hide the details and to build a fully abstract data type. Proponents of the first view argue that the student should be taught only the "right" way to do things, so that he or she will continue to do things in this way; they argue that the second approach shows the student how to avoid abstraction, and that students will not use abstraction once they know how to avoid it. Proponents of the second view argue that concrete data structures are difficult enough to understand without the abstraction, and that students can learn to introduce abstractions (and why to do it) later. The textbook for this course mainly adopts the first approach, introducing abstraction early. I prefer the second approach, introducing abstraction later, and that is the approach that I will take. So I will start off looking at low-level memory management, then see how to build interesting data structures, and then see how to encapsulate data structures into abstract data types.