Mimir:Draft1 Chapter6

From Openitware
Jump to: navigation, search

Back to Table of Contents

Chapter TODOs

  • make the picture on the right that cat thing from Scratch
  • review/update content, possible scratch code sample images
  • summary
  • exercises

Chapter 6: Visual Programming

"I look forward to the invention of faster-than-light travel. What I'm not looking forward to is the long wait in the dark once I arrive at my destination." - Marc Beland

The Visual Paradigm


The fourth paradigm this book will cover is the Visual paradigm. Visual programming languages focus on Graphic User Interfaces (GUIs) in order to create code and applications. The language we will focus on for examples will be Scratch.

Several paragraphs explaining each section, then as we get down into details move into sub sections. To have proper flow, which we will be adjusting mostly later, we can have the first section focus on that paradigm. The next section talk about the language we are focusing on in particular, etc, etc.


What Is Scratch?

Scratch is an imperative, event-driven language. Being heavily graphic in terms of an executed end-product, much of the code is based around waiting for specific events--user input, contact between sprites, variable thresholds--to occur, which trigger additional pieces of code. The code, for the most part, is dedicated to altering the state of the presented visuals.

Scratch was originally released in 2006 from MIT. Designed by Mitchell Resnick in 2003, the language itself is simple to use, underscoring the fact that it was originally put together as an introductory language for very young children. It introduces basic programming concepts in a format that lets the learner worry less about syntax and more about construction, and produces results (that aren't error reports) very quickly.

What Can Scratch Teach Us?

(Show screen shot of a piece of code)

Scratch is primarily visual; every component used to give functionality to the pieces of your Scratch program has a visible "physical" component that will need to be added. Rather than typing out commands, though, the commands are shown visually as geometric objects that interact with other objects in very specific ways. These objects' shapes are designed in such a way that they act as a pre-execution syntax check. It is impossible to incorrectly construct a statement in Scratch, because the objects won't allow themselves to be assembled incorrectly.

Although Scratch may seem to be simplistic it is a rather powerful tool that demonstrates many higher level concepts to children such as Message Passing. Message Passing is what happens when an actor or object calls a process, function, or subroutine via an intermediary structure without simply calling them directly. These functions or processes that are listening for the message are then activated and perform their own code based on what was sent to them.

Flow Control

Scratch also demonstrates how Flow Control functions within a program. Flow Control is how different possibilities are managed within a program. Without control flow, a program is essentially an ordered list of instructions to be followed one after another, and not repeated until the program is run again. Control flow gives us the ability to repeat tasks, or pull information out of order, or choose from multiple functions from the same program.

There are several main aspects to Flow Control. The first would be Loops. Loops are repeated sets of instructions. Depending on the design of the loop it may have a fixed number of repetitions, dependent on input, or it might be designed to repeat until a break is called or detected. The main idea of a loop is to continue to do a set task repeatedly, but there can be many ways to interrupt or modify it.

The second aspect of Flow Control is Conditional Flow. Conditional flow works with branching paths and possibilities. Many programmers recognize this as if-then-else statements. Operators that provide conditional flow look for certain terms to be filled. For example, "If a child receives ice cream, then they are happy." As long as these terms are met, the associated code runs. Otherwise if the terms are not met there can be code that activates in that scenario, or simply nothing at all. It is a powerful tool that is used in most programming languages today.

(Re-write subroutine calls) The final part we will cover are Sub-Routine Calls. Sub-Routine Calls have a host of different names. The one thing they all have in common is that they refer to another part of the same program that provides additional functionality to the program. Essentially, when a program reaches a subroutine call, it leaps directly to the portion of the program holding that subroutine, executes the instructions it finds there, and returns to wherever it was in the program with whatever results the subroutine is designed to provide. This may be a string, it may be numeric, it may be absolutely nothing at all.


A quick summary of the chapter should go here

Key Terms

A list of key terms should go here. This should be created using some sort of glossary type plugin.

Problem Sets

A list of practice problems

Make Your Own Game

Try making your own game! Give it a starting screen, instructions, and several playable levels!