- key terms
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."Scratch","App Inventor" are most commonly known visual programming languages.
It is an open-source web application originally provided by Google , and now maintained by the Massachusetts Institute of Technology (MIT).It uses a graphical interface and the StarLogo TNG user interface, which allows users to drag-and-drop visual objects to create an application that can run on Android devices. App Inventor includes:
- A designer, in which a program's components are specified. This includes visible components, such as buttons and images, which are placed on a simulated screen, and non-visible components, such as sensors and web connections.
- A blocks editor, in which the program's logic is created.
- A compiler based on the Kawa language framework and Kawa's dialect of the Scheme programming language, developed by Per Bothner and distributed as part of the GNU operating system by the Free Software Foundation.
- An app for real-time debugging on a connected Android device.
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.
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.
Scratch block types
Blocks are used to create code in Scratch. The blocks connect to each other like a jigsaw puzzle - this prevents syntax errors.There are six block shapes: Hat, Stack, C, Cap, Boolean and Reporter. There are eight categories of blocks:
Scratch data types
Scratch has three first-class data types:
These are the only data types that can be used in expressions, stored in variables, or returned by built in functions.
Race condition in Scratch
A race condition is an undesirable situation that occurs when a device or system attempts to perform two or more operations at the same time, but because of the nature of the device or system, the operations must be done in the proper sequence in order to be done correctly.A race condition in scratch occur when two different Sprites ask the same question and get different answers. Race condition happens when two different bits of the program "race" to do something at the same time, and the programmer doesn't have control over which "wins".
Strategies to avoid race condition
1.Avoid having more 'green flag' or other hat scripts (with rounded tops) than you need. If you can combine them without causing any problems, it's best to do that. That enables you to determine the order the blocks run in.
2.If you have a bug that might be caused by a race condition, try adding wait blocks to delay some of your scripts so they execute in an order you can influence. This is a real fudge so I wouldn't recommend it for final programs, but it can be valuable for finding bugs when you're testing your program.
3.Use Scratch broadcasts to synchronize between sprites where necessary. For example, you could have a green flag script that sets up your variables and gets everything else ready, and then sends a broadcast to start scripts on other sprites. That avoids a clash where the other sprites might be trying to use variables you haven't set up yet (for example).
4.Use the broadcast and wait block where it makes sense. That stops your script steaming ahead before getting the results it needs from other scripts that it's triggering.
Sprites: The scratch object model
Sprites are objects: they encapsulate state and behavior. Commands operate only on sprite in which they appear; one sprite cannot invoke a command such as "move" on a different sprite. Every sprite has its own independent set of scripts. This design involves a tradeoff. The scripts in a given sprite tell the entire story about entire sprite's behavior.
A quick summary of the chapter should go here
A list of key terms should go here. This should be created using some sort of glossary type plugin.
Make Your Own Game
Try making your own game! Give it a starting screen, instructions, and several playable levels!