Introduction to Systematic Programming – Week 1

For those of you just tuning in, check out the “Intro” to the Introduction to Systematic Programming series here for some more background on what we’re about to get into.

If you’ve been here since last week, I’m sure you’re waiting with bated breath to hear how the first week of classes went. Well, the wait is over!

Week 1 consisted of 9 lessons centered around the topic of Primitives in Dr. Racket. I’ll go through each lesson here one by one, giving a quick description of the main topic points we covered and any interesting additional tidbits I may have picked up. Please remember that some terms in this class, as mentioned in post 1, are used in a different manner than most traditional programming. I’ll try to note this when I can, but in some cases, I may not even be aware of how it is used traditionally, since a lot of this is new to me as well!

Lesson 1: Introduction to Systematic Program Design

The primary point covered in this first lesson is that, “Computation is what makes ‘things’ happen!” This course is based on the idea that programs, and the design of programs, is what makes the majority of our “typical” 1^st world interactions possible. From food to transportation, a computer program was likely involved somewhere in the process of the product getting from production to the end user, regardless of whether the product is regarded as “technology”.

Next, we reviewed the question, “What’s the ‘Design Method’?” In this class, the design method is defined as a structure that takes you from a poorly defined problem all the way to a well-structured solution. To me, this transcends just software development, and can be used throughout one’s daily existence if applied in a thoughtful manner.

Lesson 2: Expressions

Dr. Racket is set up such that the Definitions Area is above the Interactions area, as you can see here:

In Dr. Racket, expressions are evaluated to produce values. In order to create an expression, one should utilize the following recipe:

For example, to have Dr. Racket compute “3+6”, you would input the following into its Definitions Area:

(+ 3 6)

Additional notes from this section:

; designates a line to be commented out

#i designates an inexact number

Lesson 3: Evaluation

The Rules in Dr. Racket to Evaluate Expressions are:

1. An Expression is a “Primitive Call” when it begins as (*……

With * standing for any of the primitive Operators, including, but not limited to: +, -, /, *

1. All the items after the Operator are designated as Operands
2. The first step in Evaluation is to reduce all Operands to values
3. Operands are reduced to values from left to right, and from inside to outside

Additional notes from this session:

Remember to include spaces before operands and numbers or else your expression won’t be able to be evaluated.

Lesson 4: Strings & Images

This lesson covered how to define strings and images, as well as some of their basic functions that the course will be using. Here are some of the highlights:

Strings

“This is a string in Dr. Racket”

Strings are considered values, and are not numbers, even if the string contains a number or numeric value.

(string-append “Ada” “Lovelace”) will evaluate to “AdaLovelace”

(string-length “apple”) will evaluate to 5

(substring “Caribou” 2 4) will evaluate to ri

Substring uses Zero Based Indexing, which in layman’s terms, means that it begins counting from 0. Thus, Caribou would be numbered C – 0, A- 1, R-2, I-3, B-4, O-5, U-6.

Substring takes the portion of the string beginning with the first operand, as well as the rest of the middle numbers, but does not include the closing operand.

Images

In order to utilize images in the Dr. Racket language, the top of the program must include the line (require 2ndp/image). This references the second edition of the How to Design Book’s image rules.

To Generate a Circle

To Generate a Rectangle

Text

Above

Beside

Stack

Lesson 5: Constant Definitions

The idea of defining a constant in Dr. Racket is similar, if not identical, to what I have experienced in other programming languages. Generically speaking, defining a constant means giving a name to a value (that has been hard coded) to be used in the future. Constants are usually defined in UPPER case, to differentiate them from other types of defined values.

To define a constant in Dr. Racket, one would use the expression:  A functional example of this would be: (define WIDTH 400). This would create a named value called WIDTH that would evaluate to the number 400 when used in an expression.

Additional Notes from this Section:

Defining a constant does NOT equal an output value.

Constants can be images. For example, (rotate 10 CONSTANT) will rotate a constant by 10 degrees.

 

Lesson 6: Function Definitions

Functions are the mechanism that lets you produce a different result each time you run a program, and they can be used repeatedly with any (valid) value. In my experience, similar to defining constants, this definition is true across many, if not all, programming languages. Across languages, a parameter is the changeable value that is passed into the function.

Using functions allows programmers to avoid the “cut and paste” trap that they may be inclined to fall into in order to review multiple values, and allows for cleaner, more concise code. 

To write a function in Dr. Racket, the following recipe is used:

Lesson 7: Boolean & If Expressions

Boolean values are expressions that evaluate to either true or false; this result is also known as a predicate. There’s no in-between for Booleans, and this is also true across the majority of programming languages.

If expressions rely on this predicate in order to branch its responses. If statements ask the program, “is this true? If so, do this. If not, do this!”. In Dr. Racket, an if statement is expressed as follows:

Lesson 8: Using the Stepper

Lesson 8 reviewed how to utilize a Dr. Racket tool called “The Stepper”. This program allows the developer to evaluate their program step by step, to determine where an error may lie. It’s a great tool for those using the class, but I don’t think it’s necessary to get into too much detail here.

Lesson 9: Discovering Primitives

What I found really interesting about lesson 9 was that its basic principles seemed counterintuitive to most other types of learning, but very indicative of how I feel about memorizing theorems and methods. As this class has its own “made up” programming language for us to use, no one is intimately familiar with the primitives (or anything, really!) we have available. The advice for this is twofold. First, we’re encouraged to “Take a Guess!” because the likelihood is that since programming is intuitive, we just might be right. The second suggestion is to “Search & Scroll”, which is explained as looking up a similar primitive and seeing what else related is available in our guidebook. As I said, I’m a huge fan of this approach, because it does not force the student to memorize countless hours of specifics, but rather allows them to dive right into the interactive work and learn along the way.

ALRIGHT

That’s it for the Week 1 Lessons. I think it was a really great start because I was able to refresh a lot of basic concepts, but also get a general feel for how Dr. Racket works. The homework assignments were pretty basic and I was able to get through them with relative ease. What I did get stuck on, for those of you who are following along as fellow course students, is that when putting in evaluation results, do NOT forget the “s surrounding your strings! I forgot this and I almost failed the homework quiz because of it. Luckily, our week 1 quiz allows a retake, so I was able to fix my mistake and I’m happy to say I scored 100%.

Questions/Comments?

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

By Dara Monasch