Skip to main content

This page will help you understand the differences between how we do things in lecture/lab/problem sets/exams from the way they are in the edX videos.

The goal of CPSC 110 is to be a world leading introductory course in software development.  We aim to help you learn expert-like ways of thinking about programming that can begin a path to being an excellent software engineer.  As such, CPSC 110 it is always evolving, always improving to keep up with research and practice in programming languages and software engineering. The great thing about that is that you will learn about ideas use in companies with leading software development cultures.

But being on the cutting edge has some costs.  Because we are always improving the course, some of the scaffolding is still visible.  This shouldn't surprise students at what is sometimes called the university of building construction.   Computer science, and certainly 110, is the department of course construction.  One of the most visible pieces of scaffolding is that there are some improvements to the course that are not yet reflected in the module videos.  The cost and mechanics of updating the videos is such that we want to have a number of improvements ready before we update them next.

The purpose of this page is to explain the differences between the module videos and the other course material.

Types

In the module videos we sometimes use something called an interval type.  An interval type looks something like Integer[10, 20), which means integers in the interval from 10 to 19 inclusive.  But we no longer use interval types in the course.  They are definitely on the horizon for professional software development, but there we too many complexities associated with integrating them with some of the other improvements we have made to the course.  It is sometimes important to restrict the range of numeric values, we now do that with a constraint in the function signature, or in a data definition as shown here (module videos on the left, all other course material on the right):

edX videos lecture, labs, problem sets, exams

In a data definition:

;; Cat is Number[0, WIDTH]
;; interp. The cat's x position in pixels

In a function signature:

;; Integer[5, 10] -> Number

In a data definition:

;; Cat is Number
;; interp. The cat's x position in pixels
;; CONSTRAINT: always in the interval [0, WIDTH]

In a function signature:

(@signature Integer -> Number)
;; function purpose
;; CONSTRAINT: first argument is in the interval [5, 10]

@Tags

An emerging practice in leading software development organizations is to add annotations to programs that describe additional properties of the program's design.  Because these annotations are data about the program itself, they are called metadata annotations or metadata tags.  In 110 we uses a systematic design process which inherently generates important metadata describing how the program was designed.  In the videos this additional information always appears in comments; but we are now writing that information using metadata tags.  These tags formalize the notation for writing the information, and will also allow tools like the autograder to check the information.  All the information in the tags also appears in the videos - it just takes a different form in the tags.

edX videos lecture, labs, problem sets, exams

File header:

<nothing>

Signatures:

;; Number String -> String

Data driven template rules used:

;; Template rules used:
;; - atomic distinct: "Stopped"
;; - atomic non-distinct: Number

Origin of template:

;; template from Spaceship

File header:

(require spd/tags)

Signatures:

(@signature Number String -> String)

Data driven template rules used:

(@dd-template-rules atomic-distinct      ; "Stopped"
atomic-non-distinct) ; Number

Origin of template:

(@template SpaceShip)