On this page:
Course Theme
A Problem
A Solution
Concrete Tools
Racket Features

Why (Racket)?

Last updated: Sun, 3 May 2015 12:57:45 -0400

This page explains some course philosophy.

The first thing you need to know: this course is not about programming in Racket (or Java, or any other specific programming language).

Course Theme

This course is about program design.

As David Parnas cautioned:

"Unless we teach people how to design, the languages matter very little."
as quoted in The Mythical Man-Month [MythicalManMonth]

A Problem

In general, software engineering suffers from a dilemma. On one hand, almost anybody can write some code that "works" and thus many people think they know how to "program." On the other hand, nobody wants these sloppy, unorganized programs that often:
  • cannot handle anything beyond a few narrow test cases;

  • are difficult for others to read and understand;

  • are poorly designed and thus difficult to extend and maintain;

  • have behavior that is not well-understood and cannot easily be explained, even by their authors.

Anyone who has ever been frustrated while working with someone else’s code understands this dilemma well.

Unfortunately, this dilemma is extremely costly in practice, for startups and established companies alike, because it leads to the accumulation of technical debt.

Thus, despite the hype you might hear about interviews focusing on cute, algorithmic questions, what quality software companies are ultimately looking for are programmers who can write clear, readable, and maintainable programs.

A Solution

To address this dilemma, we teach "program design" in this course. In other words, we teach you to how to think and organize your program before you start writing any code.

Skilled program designers:
  • create programs that are well-tested and correct;

  • write clear and readable code;

  • write well-structured programs that are changeable and maintainable;

  • can effectively communicate their ideas and their code to others.

To achieve these goals, we teach a systematic approach to the creation of code. Programmers following this methodology not only create readable, maintainable solutions, but also:
  • are never stalled in front of an empty editor because they always know where to start with their program design;

  • always have a next step and thus spend less time being stuck when debugging;

  • automatically have a means of explaining their programs to others.

This course begins with a basic program design recipe. Then, throughout the semester, we extend and refine the recipe to accomodate various contexts and styles, and hone your program design skills through deliberate practice.

Concrete Tools

Students frequently inquire about our choice of tools for this course. Though the question has been generally answered before, this document supplements the previous answers.

Given that we don’t know which future programming languages will be popular, or what future problems you’ll be solving, this course strives to teach program design in a language-agnostic manner. We try to avoid being constrained by language-specific ideas and constructs as much as possible, in hopes that the programming skills you learn are applicable regardless of whatever future programming language you happen to be using.

Another danger of focusing on a specific language is that it’s easy to overlook what the language cannot do. For example, regarding the well-known C++/Java/OO Design Patterns Peter Norvig famously observed that 16 out of 23 patterns are not even needed in other languages like Lisp or Dylan.

Racket Features

Of course, to learn program design, we must write actual programs. Thus, we must choose concrete tools to program with.

We use Racket in this course for several reasons: