In the event that you’re just joining in, here’s a guide to the rest of this series:

Intro to “Introduction to Systematic Programming” Course

Introduction to Systematic Programming – Week 1

Introduction to Systematic Programming – Week 2

Introduction to Systematic Programming – Week 3

Like I said when I was writing Week 3’s post, Week 4 was crazy complicated. However, I will candidly say that since I had a feeling the week was going to be harder, I really did spend more time walking through the coding of these new systems and I think that made a HUGE difference, because on Week 3’s Quiz I got a 7.50/11, and in Week 4 I achieved 9.7/10. So, take that how you will!

Lesson One: Interactive Programs

As for the focus of Week 4, the subject matter is the How to Design Worlds Recipe, as well as an introduction into Compound Data.  This means we started to learn the functionality needed to build things like animations, games, and, eventually, desktop apps, as well as how to utilize basic graphics, as always, all in Dr. Racket.

Lesson Two: The Big Bang Mechanism

As expected, the “Big Bang” mechanism is an amusing reference to the creation of the actual world, and it’s used in Dr. Racket as the “mechanism that supports interactive programs” – in actual usable terms, Big Bang is an expression that wires 2 or more functions together, to create a world state. This lesson encourages the students to watch some programs and try to decipher how they might work, and what sorts of functions they might need. It then goes on to explain that programs manage things that *change* and if your program doesn’t change anything, it wouldn’t be very useful, now, would it?

Here’s the initial example of Big Bang that we’re given in class, along with some notes:

(big-bang  0 ;; Cat

(on-tick next-cat) ;; Cat-> Cat

(to-draw render-cat)) ;; Cat->Image

The first line of big-bang evaluates to create the initial world state. After that, there are different functionalites of big-bang, those that will be wired together, explained inside the ()s of big-bang. The way the instructor explains this, again, is that it “squeezes” the functions together to produce the world you’re designing inside.

You’ll see ;; notes next to the function names – these are called “function signatures” and they help the programmer to flesh out how these big-bang abilities will be built into functions later in the program.

Extra Notes from This Lesson:

1. Place-image is a function that puts an image at designated x,y coordinates.
2. MTS displays a new screen

Lesson Three: How to Design Worlds Analysis

As with every other part of Introduction to Systematic Programming, there is a recipe for how to create worlds, known affectionately as “How to Design Worlds” or HtDW. There are two phases to this recipe, and lesson three walks us through the first portion, Domain Analysis.

Domain Analysis has 4 steps:

1. Sketch Program Scenarios

2. Identify Constant Information
– These are the things that do not change through the course of your program
– Try to identify as many of these as you can during this phase of domain analysis; however, if you think of one later, it’s totally ok to add it in at that time!

3. Identify Changing Information
– These are the things that DO change through the course of your program.

4. Identify Big-Bang Options
– There’s a handy table in your class references to assist with this:

Extra Notes from this Lesson:

Templates are NOT only for beginners! They should be considered an expert’s way to outline the basic structure of a complex problem before diving into the details! They allow the designer to consider the question, “given that I’m using this structure, what do I know is “known” to be true?” and thus break down their problem.

Lesson Four: How to Design Worlds – Program Through Main Function

The second step in designing a world after Domain Analysis, is Building your Program! There are also four steps to consider here.

1.    Constants (Base this on 1.2 from Lesson 3)
a.    Consider tracability between the code/analysis. This means that your domain analysis should be easily referable so that you can complete your coding! If you have a constant in your analysis, you should have it in your program and you should be able to go back and figure out which is which, EASILY!
2.    Data Definitions (Base this on 1.3 from Lesson 3)
a.    For this item, we would use our typical Data Definitions recipes that we learned previously in the course, and refer to the appropriate references.
3.    Functions!
a.    Main Function (based on 1.2 and 1.3 from Lesson 3)
b.    Wishlist Entries
i.    A wishlist entry is the stub of a function that you need to create in order to get the program to run! This is based on 1.4 from Lesson 3, in which we determined which Big Bang options we needed to utilize for our world to act in the way we desire. A wishlist entry should be made for each of these options so that we remember to go back and code them in step 4!

Lesson Five: How to Design Worlds – Working Through the Wishlist

4.    Work Until You’re Done!
a.    Code. Code. Code. Code! (Oh, and TEST!)

It’s noted in this section to make sure that you WORK SYSTEMATICALLY!! Don’t jump around like a crazy person. The HtDF/HtDW method and recipes are structured to assist you with working through your program in a systematic fashion, focusing on one thing at a time until you’re done. This lets you break up the difficult aspects of a complex problem into smaller, more managable chunks.

Lesson Six: Improving a World Program – Add SPEED!

The most important takeaway from lesson six is to always remember that the Domain Analysis is simply a MODEL of the program you’re working to create. If you want to add on to your program, you can use that model to plan out your program/changes you want to implement.

Lesson Seven: Improving a World Program – Add a Key Handler

Key Handlers in Dr. Racket are handled by the Big Bang option, “on-key”. These Key Events are of the primitive datatype and constitute the first “large enumeration” that we are seeing in this class. Large enumerations are exactly what they sound like, having a list of specific values for a specific list of items. When using a large enumeration, it’s important to remember to “white box test”. As we know, typically for an enumeration, we would write a test for each item on the list. However, for a large enumeration, this is not practical, so we would want to test a correct response, a wrong response, as well as an equivalent response, to cover all potential instances of response that the function might produce, as opposed to testing each item one by one.

To create these key event functions, the template used is a cond, with a Q/A pair for each special case. For example, if you’re looking to answer a yes or no question with “Y” and “N”, you would write a cond for Y and X, and then finish with an “else” clause, because the rest of the enumeration list would produce the same results!

Lesson Eight: Define struct

I was really excited when I saw this lesson title, because I learned about structs in my last class, CS50x on edX, so I had a feeling I would have a bit of an advantage when watching this session… and I was right! Thank goodness, because I was getting kind of overwhelmed this week.

So ok, what is a struct?

A struct is a compound datatype that takes two or more values that naturally belong together and weaves them into one shiny new piece of data. Structs are formed with the following template:

Here’s an actual struct example:

(define-struct pos (x y))

In this example, the first name is replaced with pos, (interpreted as position) and the next name(s) given are x and y, which become the field names. These field names can be accessed later in the program by using the selectors, which in this example would be pos-x and pos-y. Structs also have a predicate, which in the case of this example would be pos? .

Lesson Nine: Data Definitions

Complex Data, again, is two or more values that naturally belong together. This receipe is very similar to how we typically define data, and utilizes the following five steps:

1. Determine the Possible Structure Definition
2. Determine the Type Comment
3. Write the Interp
4. Form Examples/Tests
5. Template the Definition!

Week 4 Summary

As mentioned this week was a doozy! However, I really appreciated the last lesson in the week, which I didn’t put notes down for because honestly, it was a full-fledged walkthrough/review of everything we’ve learned so far. We were given a Dr. Racket starter template and got to build the program right along with our instructor. I found this *incredibly* invaluable, even moreso than the homework problems and practice problems. Honestly, I think this is because we were able to see the methodology behind the answers, as opposed to just getting the answers like we did for the homework in week 1 of the class. There was one important item that was covered here that I think bears mentioning, though. When writing your program, it’s totally, totally ok to refine what your original plan was while you’re working, as long as you think it through. Specifically in Dr. Racket and this class, we’re encouraged to write functions that ONLY do one thing, so sometimes when I’d initially had one program vision, I may have to revise it based on instructions or the design recipe. That’s ok! We’re taught in the class that this is the difference between a “coder” and a “program designer” – make sure you’re the kind of developer who thinks and truly who designs her programs!

Questions/Comments?

Feel free to comment here on my blog, or find me on Twitter @DokiDara.

By Dara Monasch