CSC 202, Spring 2024
1 Overview
This course is an awesome course. It’s the next course for you, and you’re incredibly excited about it. So are we!
Yes, we can be more specific.
In 101, you learned the fundamentals of programming. In particular, you worked hard and created a sequence of programs of increasing difficulty. What’s next?
In order to create the programs that you want to create, you need to be able to apply these programming skills to your particular problem domains. Computer Scientists like to make a lot of noise about algorithms, but most of the time, the place where the rubber hits the road is in the design and selection of data structures. That’s what this course is about!
1.1 Can you give me more detail?
We sure can!
Let’s consider some examples. Suppose you’re designing a program to save the world by tracking patterns of educational success, and the correlation between geographic area and academic achievement. In order to do this, your first core task is to figure out how you’re going to represent this data.
Choice number one: A huge long string. This would be a terrible choice; processing English text is notoriously error-prone, and we have whole courses (cf. Natural Language Processing) devoted entirely to extracting shreds of meaning from the gibble-gabble that humans generate when they communicate.
Choice number two: a list of people, where each person is a structure containing a name, a location, and the score on the SAT. This is a lot better, but might be very inefficient; for instance, isolating the mean SAT score in a community would require scanning the whole list of three hundred million people.
Choice number three: a hash table mapping zip codes to lists of people. This would probably be pretty good... except in situations where an educational community doesn’t align well with zip code boundaries.
Choice number four: a geographic tree, where each tree split corresponds to a bisection of a geographic aread. This also has advantages and disadvantages.
As you can see, the list is long, and the choices you make will influence nearly every aspect of later development. The history of software is rife with examples of poor data structure choices leading to much developer pain and suffering or simply to product collapse.
1.2 Do you have a Hidden Agenda?
Yes! We do!
The single largest problem in software development is that of managing complexity. Put differently, the central problem is scale.
It’s not hard to write twenty-line programs; you fiddle around until it works. When you get up to 200-line programs, some of the things that worked in the small don’t work any more. When you get up to 2,000-line programs (and believe me, you’ll be there very very soon), many of the things that worked for smaller programs fail again. Scaling up is extremely difficult. In fact, this is the central skill that separates programmers from engineers that program: programmers know how to design programs in a way that will be robust at 20, 200, or 200,000 lines of code.
In this course, We’ll be teaching you a “Design Recipe.” This design recipe will provide specific numbered steps involved in developing a program. Following these steps will guide you toward solutions that are correct, and solutions that scale well.
1.2.1 But what about my creativity?
You might worry that following a design recipe will stifle your creativity.
Don’t.
In essence, the design recipe is all about preventing you from struggling with the easy problems, so that you can get more quickly to the difficult problems. To see this, consider training a painter. Do you want to spend your first ten weeks trying to figure out which end of the paintbrush to apply to the canvas? You do not. In a similar way, the purpose of the design recipe is to enable you to program fluently, in order to get you more quickly to challenging problems.
2 Prerequisites
Students taking this class must have completed CSC/CPE 101 or the equivalent. They must also have open minds, be willing to support others in their learning, and be prepared to experience significant awesome.
3 Names, Times, Locations
3.1 Instructor
John Clements, clements@calpoly.edu
3.2 Lecture & Lab
Section 11/12 (Clements):
Lecture: 14:10–15:00, MWF, room 180-113
Lab: 15:10–16:00, MWF, room 14-302
3.3 Office Hours
John Clements: https://brinckerhoff.org/index.html
4 Web Page
This is the course web page, its link is http://www.brinckerhoff.org/clements/2244-csc202.
5 Lecture Classroom
I think that an interactive and lively classroom is a better learning environment. In particular, I will almost certainly learn everyone’s name, and I’m likely to notice if you’re missing. My experience is that if you come to class reliably, you’re extremely likely to pass the class—there’s a reason that we conduct classes face-to-face; it keeps you engaged, and ensures that you’re connected to the other students in the class.
In addition, I’m likely to call on you, in places during the lecture where I want to see if you’re following what’s going on. If you don’t know, it’s totally fine to say "no, I have no idea." In particular, this is probably evidence that I’m going too fast or not explaining things well. However, I try to respect the wishes of students for whom this technique is disruptive. Please let me know if you don’t want me to call on you.
Finally, my experience standing in front of classes and more especially my experience of sitting behind classes has convinced me that laptops are useful for note-taking in approximately 1% of cases. Essentially, never.
Indeed, there’s now a mountain of evidence indicating that laptops are distracting to students and to those around them, and that even when these distractions are eliminated, taking notes on laptops fails to create learning in effective ways. I’ll just cite this one paper, because it’s got copious references to other sources.
For this reason, I do not allow the use of laptops in class without special dispensation. If you need to use a laptop to take notes, please come and talk to me; otherwise, just put it away and take notes on paper.
6 Computing Environment
You will be required to complete the assignments in this class using Python 3.12. It is freely available for all major platforms, including Mac OS, Windows, and UNIX.
We do not require you to use a particular IDE (Integrated Development Environment), but we invite you to use PyCharm, and promise to do our best to support users that use it.
6.1 Handin Server
This class will be using GitHub Classroom. That means that for each assignment, you’ll be clicking on an invitation link in order to create a fresh private repository for your assignment. You’ll do your work in that repository, and as you’re working on the assignment, the handin server will be periodically checking your work. This means that you’ll probably get lots of e-mails indicating that your project isn’t working yet; don’t worry about this. The only score that matters is your final score.
I would also be remiss if I didn’t say right up front that this system is still under development; I can pretty much guarantee that there will be problems. On the other hand, I’m extremely confident that github won’t lose your code; if you push your changes up to github, they should stay there.
7 Communication
This class will use EdStem. This will be the principal means that I’ll use to notify you of deadlines, organizational updates, and changes to assignments. If you’re not keeping up with the group, you’re going to be missing important information.
It’s also the best way for you to direct questions to me and/or the class. Feel free to e-mail me with personal questions, but use the EdStem group as your main means of communication. It’s possible to post anonymously, if you like.
You should already have received an invitation to the EdStem group; let me know if you need an invite.
Don’t post your code or test cases to the group; anything else is fair game.
Also, please keep in mind that I (and everyone else) judge you based in part on your written communication. Spelling, complete sentences, and evidence of forethought are important in all of your posts & e-mails. One easy rule of thumb: just read over what you’ve written before clicking post or send, and imagine others in the class reading it.
8 Honesty
We strongly encourage collaboration among students in almost every aspect of the course. See, for example, the following section on "Labs", which are designed for collaboration.
One exception is for quizzes and tests, which must be entirely your own work.
The other exception is for programming assignments: you may not copy another team’s code, not even test cases. You are also responsible that no other teams see your code, either during this course or afterwards, either deliberately or through negligence (e.g. via a non-private repo).
A very effective automated tool will review submissions for evidence of copying. Students believed to be cheating, i.e. both parties involved in a transfer of code, will in the first instance typically receive a 0 score for the assignment, and an additional unspecified penalty on the quizzes and tests that follow, often about 10%. We reserve the right to assign a failing grade in the class when appropriate.
Please note that the baseline score for assignments that you DON’T HAND IN AT ALL is typically about 15%. Plagiarism will result in sacrificing that 15% baseline. This means that copying code is likely to produce a score that is lower than doing nothing at all.
8.1 If it is late and you are desperate
Please submit what you have. You will get partial credit, even if the handin server says "handin failed". It is way better to submit something terrible that is your own work than to submit someone else’s code. It’s okay. Let’s talk about it. Keep in mind that I want you to succeed.
9 Labs
Labs in this course take the form of simple exercises to be completed in a week during lab periods, designed to help you understand the lecture material and to lead you toward solutions for the larger assignments.
Some instructors will be checking these labs off during lab. Others will simply ask you to submit them to the handin server. Talk to your instructor to find out what’s happening in your class.
The labs will be due at the end of your lab period on the day specified, typically Monday.
In labs, you are heartily encouraged to collaborate like crazy. Look at everyone else’s code, copy and paste, type on your neighbor’s keyboard, whatever. Labs need not be entirely your own work.
10 Assignments
Programming assignments will be due at 11:00 PM.
11 Grading Code
Different instructors will be grading code differently. Talk to your instructor to see what standards she or he applies.
12 Quizzes and Exams
The frequency of quizzes will depend on your individual instructor.
There will be two midterms and a final exam in the course. The midterms will be during the lecture period in the fourth and seventh week of class. The quizzes and exams will be closed-note. No electronic devices, including calculators, phones, or mp3 players, will be permitted during the quizzes or exams.
13 Grades
Grades will be determined by performance on programming projects, the exams, and class interaction. A small fraction of the grade is determined by the labs, and by the instructor’s whim. The breakdown of the grade is as follows:
Assignments : 30%
Quizzes : 14%
Midterm : 14%
Final : 27%
Labs : 10%
Other : 5%
14 Lab Grading
For each of the first two labs, I will be randomly assigning you to work with a lab partner. (Not the same one; I roll the dice twice.) After the second one, we may decide to go with lab partners for the rest of the course... or we may just give up. We’ll see.
When you successfully demonstrate a lab, I will give you a number. You may enter these numbers at https://handin-1.brinckerhoff.org/servlets/standalone.rkt .
15 Assignment Grading
I will be grading your code repeatedly in this class. On most assignments, your score will consist of a part (usually 20 points) based on your performance on a set of test cases automatically administered by the handin server, and a part (usually 6 points) based on my opinion of your code’s clarity, organization, and adherence to rules about purpose statements and contracts/types (in short: you’ve got to have them). As a rule, my "eyeball" score rubric runs something like this:
6 points – Your code displays unusual clarity or elegance, with no problems of consequence.
5 points – some inelegant parts, or one or two purpose statements or contracts/types missing
4 points – an actual misunderstanding, or a widespread lack of purpose statements and contracts/types
3 points – a serious misunderstanding–you didn’t understand some major part of the assignment, or I had to work to try to get your code to compile or run without looping
2 points – your program is seriously incomplete, doesn’t compile, or has widespread major problems
1 point – you didn’t make any apparent progress on the program at all.
Finally, please note that I will place comments in some of your submissions indicating errors or stylistic requests. These will all begin with the string ;;> (in Racket) or ##> (in Python), so you can search for these in the e-mail that you get with your final assignment grade.
15.1 Code Organization
Here’s the most important thing to know about code in this class:
I do actually read it. That means that—
This means that getting your code to work is not the end of the process; after you get your code to work, you have to clean it up, put nice headers on the various parts, collect the test cases, document strange things that you did, and clarify the code.
You should begin with a single-paragraph comment that describes how far you got: did you finish, or did you get stuck on something? If you got stuck, describe what’s done and what’s still left to implement.
As a rule, I like to read code in a "top-down" way. This means that the definition of the top-level, important functions should come first, and the supporting functions should come later. I want to have a good understanding of the big picture before getting into the details. My experience is that if interp makes sense, then add-to-env will probably not present any difficulty.
Another part of cleaning up the code is collecting the test cases in a place that’s sensible and doesn’t interrupt the flow of reading the code. It’s probably best–after you’re done writing the code–to collect the test cases at the bottom of the file (or put them in another file altogether, if appropriate).
Whatever language you use, it’s likely to have a style guide. Here’s the one for Racket. You’re not required to follow any style guide, but anything that makes your code hard to read could hurt your score.
Finally: dead code is misleading and makes code hard to read. Delete it.
15.2 "But it Works!"
I reserve the right to assign bad scores to programs that work correctly; if I don’t think you’re doing a good job of programming, then you won’t receive a good score. "It works" isn’t a defense for bad code.
15.3 Grading Time Limit
Good code is easy to read. I reserve the right to allocate a fixed period of time to grading a program submission. Don’t be surprised to see comments like "ran out of grading time here."
Naturally, all grades contain an element of subjectivity.
16 Quizzes
My experience suggests that frequent quizzes are a good way to ensure that you’re understanding what I’m teaching, and that I’m teaching things that you understand. You don’t like taking them, and I don’t like grading them, but they do actually seem to help quite a bit.
This class will have quizzes in weeks 1, 2, 3, 4, 5, and 8. These quizzes will probably be fifteen minutes long, and will probably take place during lab.
17 Assignments
Your last GitHub “push” before the assignment deadline will be graded as your submission.
From time to time, we may examine student code, in lecture. Try to ensure that the code you submit is something you’d be proud to show to the others in the class.
Late Policy: Except for exceptional circumstances, late assignments will be given 0 points.
18 Checking your Grade
I like to share your current grade in the class with you. It usually takes me a few weeks to get this set up, but you should eventually be able to check your student grade at
https://users.csc.calpoly.edu/~clements/student-grades/<your-login>/current-grade.txt
That’s not a clickable link, because you’ll have to edit it to add your login. So, for instance, if your name is Annette Czernikoff and your login is aczernik@calpoly.edu, you’d put aczernik in the login spot.