Saturday, April 17, 2010

The language of Objects

I promised you last time that I would go over some of the terminology associated with object oriented programming (OOP) this time around. So let's do it using Alice. Start up Alice and create a new world using the Space template. Click the Add Objects button and scroll until you find the Space category and select it. Here is our first term associate with OOP, class. At the top of each entry in gallery it reads "Class something or other". Select Class LunarLander and add one to your scene.

Class and Instance - Making Objects
All OOP environments establish a class hierarchy. At the top, or root, of this hierarchy is usually a class called object. The object class isn't usually used to create actual objects, or instances, it is often called a meta-class. A meta-class is a class that is used to define other classes. OOP takes much of its structural ideas from how we deal with things in the real world. I'll use a real world example that I've used in the past when teaching programming courses.

For this thought experiment I want you to imagine that you have several writing instruments in front of you: a #2 pencil, a blue ball point pen, a red ball point pen and a black felt tip marker. Our object hierarchy will look something like this:

Object
  |---->WritingInstrument
               |---------->Pencil
               |---------->Pen
                            |---->BallPoint
                            |---->FeltTip


The classes don't create anything in our program, or in the case of Alice, in our scene. The class is a template, a definition of what an object might be. Two other terms you need to know, superclass and subclass. When we look at the hierarchy, WritingInstrument is a subclass of Object and the superclass of pen and pencil. With the exception of the root class all classes are a subclass of some other class. All classes except those at the bottom of the hierarchy are also superclasses of the classes below them. Each class can be used to create multiple instances or objects in our program or scene. Let's do that now. Return to your Space scene and add two astronauts to the scene with the LunarLander. When you return to the main Alice screen you'll see that the Object tree in the window looks something like this:
You'll notice that we have two separate objects, astronaut and astronaut2, these are instances of the astronaut class.

Properties and Methods - Defining an instance
One of the things that a class defines are properties of an object. Properties are those things that describe and define an object. They are often defined at the highest level in the hierarchy where they are appropriate. Going back to our writing instrument example the properties of color and tip would be defined at the WritingInstrument level. All WritingInstruments would have these two properties. A property such as InkType would be defined at the level of Pen. We can see from this that BallPoint and FeltTip probably wouldn't be separate classes. Both are members of the pen class but with a different value for the tip property.

Methods define how an object behaves. Continuing with the writing instruments the most important method would be the write method. This is the process of how the object writes on a paper or some other surface. This method would be defined at the level of the superclass WritingInstrument, but with no function. The pen class would redefine, or overload, the method with something like, "Applies ink to paper". A pencil on the other hand would have it's write method be, "Leaves trail of graphite on paper."  In Alice any actions we define are called methods.

Two other terms often associated with OOP are encapsulation and polymorphism. Encapsulation is the idea that the object is self contained. It carries all of the information within its definition to exist within the program. When properly constructed an object can exist in multiple programs without need of anything from the containing program to define itself. We've already discussed the concept of polymorphism. It's the idea that subclasses can redefine a property or method with more specificity than the superclass. For example pencils may define tip as have one of the following values: sharpened, mechanical, replaceable. A pen would have a tip that might be: ball point, felt, nylon or nib. (That last one is for the fountain pen users in the group.) So each has a tip property but it is defined specific to the subclasses needs.

Alright enough of the language lessons, let's get our astronauts doing something. First things first let's identify our astronauts. In the object tree right click astronaut and select rename. Change the object's name to Neil. Repeat the process for astronaut2 naming it Buzz. Click on the + next to Buzz and open the list of objects that make up Buzz. Find the helmet object and open that up. Select the visor object and open that. In the space below the object tree select the Properties tab. For color set the visor color to red. Repeat that process for Neil setting his visor color to blue. Now we can tell the astronauts apart.

Add the following to your My First Method:

  1. Drag a Do Together box into the window.
  2. Drag 2 Do In Order boxes into the Do Together box
  3. In the first Do In Order box add the following:
    1. Click on Neil, select the Methods tab and drag a Neil Turn method into the box. Have him turn 0.25 turn right.
    2. Drag the Wait option and set it below the turn option. Set the wait value to 1 second
    3. Drag a Neil Move method and set the distance to Other, 2 meters.
  4. In the second Do In Order box add the following:
    1. Click on Buzz and select the methods tab. Drag the Buzz Move method and set the values to Up 0.5 meters
    2. Add a 0.25 second wait
    3. Add Buzz Move down 0.5 meters
    4. Add Buzz Move up 1.0 meters
    5. Add a 0.5 second wait
    6. Add Buzz Move down 1.0 meters
  5. Below the Do Together box add a Do In Order box.
  6. Add the following to the Do in Order box:
    1. Using Buzz add: Buzz turn to face lunarlander.ladder
    2. Add Buzz Move To lunarlander.frontleg
    3. Add Buzz Move To lunarlander.ladder
    4. Click the Properties tab and drag the Opacity property to the Do In Order box and set the opacity to 0 (invisible)
    5. Add a 1.0 second Wait
    6. Using Neil add: Neil Turn to face lunarlander.ladder
    7. Add Neil Move To lunarlander.frontleg
    8. Add Neil Move To lunarlander.ladder
    9. Click Properties tab and drag the Opacity property to the Do In Order and set the opacity to 0.
Save your world and play the scene. Congratulations on your first moon walk.

Saturday, March 20, 2010

Alice and the world of OOP

In this post we'll introduce Alice, described on the web site as:
Alice is an innovative 3D programming environment that makes it easy to create an animation for telling a story, playing an interactive game, or a video to share on the web. Alice is a teaching tool for introductory computing. It uses 3D graphics and a drag-and-drop interface to facilitate a more engaging, less frustrating first programming experience.

The splash screen for the software describes as a free gift from Carnegie Mellon. We'll be using version 2.2 for Windows in these examples.


In this entry we'll build a simple Alice world with one object and a few instructions. Download and install Alice 2.2 from the alice.org website.

Playing in the Sand
When you start Alice you will presented with an initial dialog box that is positioned on the tutorial tab. I encourage you to do the tutorials, but for now click on the Template tab. Select the Sand template and click Open. I want you to think about what you are doing and play with the software. As such I will not be including any screen captures with this exercise. Whatever you get is "correct".

The main Alice window is divided into several parts. In the top center is a small preview window of the world. In the lower right is a small green button labeled Add Objects. Click that button to open the object gallery. You will see that Alice provides a wealth of objects to play with. Scroll the object groups list until you find the Sports category. Click on the Sports category and then select Beach Ball from the list of available objects. Click the Add Instance to World button. Then click the Done button in the gallery. You should now be back at the main window with a beach ball sitting on your sand.

Let's make our beach ball do something and then we'll talk terminology and what the different areas of the main window indicate. We'll be working in the section of the screen labeled world.my first method. We won't worry about the parameter and variable sections right now. We're going to add some actions where it currently says Do Nothing. At the bottom of this section you will see several process control instructions. Click on the Do In Order instruction and drag it in place of the Do Nothing instruction.

In the upper left of the screen you will see a list of all the objects in your world. Click on the beachBall object. This will change the contents of the lower left pane in the window. It now displays things related the beach ball. Make sure that the Methods tab is selected. (This should be the default.)  The first instruction listed in the methods area is beachBall move. Click on the method and drag it into the window where the Do Nothing indicator is below the Do In Order instruction. You will then be prompted to select a direction and an amount. Select up and 5 meters to have your instruction added to the method. Save your world using the option from the File menu. Then click the Play button in the upper left. The Alice World window will open and you will see your beach ball rise into the air and out of view. Congratulations you've built your first Alice world! Let's add some additional instructions to make it a little more satisfying.

What goes up...
Let's add an instruction that brings the ball back down to the sand. Drag another copy of the beachBall move method into our world method pain. This time reverse the instructions and have it move down 5 meters. Save your world and then Play it. Better the ball goes up and then comes back down.

Let's enhance the process with a little sound. In the method list find the beachBall play sound method. Drag it below the second beachBall move. Select thud1 as the sound to play. Save and play your world. Not great but at least there some audio. We'll add one more sound that will require us to modify the program a little bit. Grab the Do Together instruction from below the main method code. Drag it up above the first beachBall move instructions and drop. Drag and move the first beachBall move instruction into the Do Together instruction. Then drag a new beachBall play sound instruction into the Do Together grouping. Select the whoosh1 sound to play. Save your world then click Play.

Much more satisfying as the ball makes a sound as it flies up and another as it lands. Experiment with this world and also the tutorial worlds. Next time we'll explore the terminology of Object Oriented Programming and how that applies to Alice.

Wednesday, March 3, 2010

Moving Beepers

As promised in the previous post here is a world and some code for moving beepers.

First the world definition:
robot 2 2 N 0
wall 2 2 W 8
wall 2 9 N 8
wall 9 2 E 8
wall 2 2 S 8
wall 6 2 W 3
wall 6 7 W 3
beepers 5 9 1

If you saved the "two rooms" world file this is the same thing with a couple of changes. First off the last number on the robot line is now 0. This indicates that Guido starts off with no beepers in his beeper bag. The other change is the addition of the beepers line at the end.

Now for some code. Since we don't have an indicator of when to stop, like the bag full of beepers in the previous post, we need to do a counted loop. I made some changes in approach to allow counting the corners that the robot hits. The code looks like this:

define turnright:
   
do 3:
        turnleft

do 
8:
    while front_is_clear:
        if left_is_clear:
            while left_is_clear:
                turnleft
                move
        else:
            move
   
turnright
    if
any_beepers_in_beeper_bag:
        if not_next_to_a_beeper:
            putbeeper
    else:
        if next_to_a_beeper:
            pickbeeper   
turnoff

The main thing here is that we are looking for corners so the while loop is controlled by the front_is_clear condition.

Changes to try: Put the do 8 loop inside of another loop, for example make a do 4 loop. Then indent all of the rest of the code in by 4 spaces at the beginning of the line. Change the number beepers at the point indicated to 4. Run the program and GvR should do 4 laps and place one beeper in each corner of the "second" room.

That's it for now. Next time we'll switch gears to Alice for a little while.

Monday, February 15, 2010

Beep, Beep!

There is a feature of GvR that we haven't yet explored, beepers. In this first look at beepers we will simply have GvR place some beepers on the map. But we'll also build on what we've learned so far as we do it.

Two rooms, No View
To start with we'll need a map for our program. Two things you'll notice about the following map code that is different than what we've had before. First the last number in the robot line is not zero. This indicates the number of beepers in GvR's beeper bag. We'll start with 8, because there will be eight corners on this map. The second change is the addition of a number at the end of the wall statements in the map file. These numbers indicate the length of the wall, up or to the right, from the starting position, up for NS walls, right for EW walls. Enter the following into the world editor and save it as tworooms.wld

robot 2 2 N 8
wall 2 2 W 8
wall 2 9 N 8
wall 9 2 E 8
wall 2 2 S 8
wall 6 2 W 3
wall 6 7 W 3

Once the code is entered and saved, click the reload button. You should have something that looks like this:
 
The plan is to have GvR place a beeper in each corner of the room. One of the sample programs provided on the GvR site shows how to have the robot hug a wall on its right as it moves around. We'll do something similar but hug the wall on the left. When we hit a corner we'll need to turn right so we'll include our turnright definition in this program. So let's break down the steps:
1. Place a beeper in the corner that we are starting in.
2. Move forward along the wall until we hit the corner
3. Place a beeper in the corner
4. Turn right
5. Repeat steps 2-4 for each of the remaining corners on the map.

Seems simple enough. We'll make use of some of the conditions that GvR can test. These are listed on the Language Reference tab of the GvR interface. To start with we'll need the left_is_blocked and front_is_clear conditions.

Let's get started. First thing we do is define the turnright command.

define turnright:
    do 3:
        turnleft

The first step in our list of steps is easy. You place a beeper by using the putbeeper command.

Following the left wall is done by making sure that the left side is always blocked, using the left_is_blocked condition. The next thing we need to know is whether we can move forward. To move forward the front must be clear. So we check front_is_clear and move if it is. If the front is not clear then we are in a corner. So place a beeper and turn right. Here's the code for that.

while left_is_blocked:
    if front_is_clear:
        move
    else:
        putbeeper
        turnright

We've seen the while command in our first exercise. It will loop will that condition is true. The if command is what we call a flow control statement in programming. It will allow us to do a group (or block) of commands based on the results of the conditional test. In this case we check if the front is clear, if it is we move. If it's not then the else clause is executed. In this case we put a beeper and turn right.  Seems simple enough.

Don't for get to include the turnoff command at the end of your program.

Once you've got your code in, save it then click Reload and Execute.
Did the program do what we wanted? Not really, did it. There's one piece missing from our initial analysis and from this code. What do we have the robot do when it reaches the opening in the wall? If we want to follow a wall on the left then when we reach an opening we know we can move to the left. So while there is no wall on our left we turn left and move forward. Use the following code:

while left_is_clear:
    turnleft
    move

Place this code before the turnoff command and save your program. Then Reload and Execute to see what happens. Better? GvR should have made it around the wall and be ready to follow the left hand wall again. How do you start him up again? Since we know we'll hit the opening twice we could try putting everything inside a do 2: loop. Give that a try and see  what happens. We're getting close. GvR stops after making back into the first room. But he still has one beeper to place to finish the task. You could up the loop to 3, but I'll tell you that an error would be generated when we attempt to place a beeper with none in the bag. What follows is my final version of this program that will place beepers in every corner and shutdown the robot when it returns to its starting place. There's a repeat of the check on beepers when we hit the corner. Again if we attempt to place a beeper and there is none the program will error. Also this shows that the end of the program, the turnoff command, isn't always at the end of the code.


define turnright:
    do 3:
        turnleft

putbeeper
while any_beepers_in_beeper_bag:
    while left_is_blocked:
        if front_is_clear:
            move
        elif any_beepers_in_beeper_bag:
            putbeeper
            turnright
        else:
            turnoff
    while left_is_clear:
        turnleft
        move


That's it for now. Here's something to try on your own. Right a program that looks for beepers in the corners of the room and if it finds one moves it to the next unoccupied corner. You can place beepers on the map in a world file using the beeper instruction. It includes the coordinates and the number of beepers. You might want to play with the GvR world builder to learn the syntax.

I'll post a version of this program in about a week so you can check your code against mine. 

Tuesday, February 2, 2010

GvR:Teaching your robot new tricks

We will look at the same topic here that is addressed in Tutorial 5 of the GvR lessons. If you've worked through the lessons this will be review. If not you may want to look at that after you've read this.

As we saw in the previous post on GvR the robot is limited to moving forward and turning left. This may seem like an artificial limitation but I'll give you an example of a simple robot, built with Lego Mindstorms that had the same limitations. The mind storms kit came with two motors. If you wanted a mobile robot that did more than move you had to accomplish the movement with one motor. Working from plans published online and in some Mindstorms books I had, I built a robot that was similar in function to GvR. One motor was used to move the robot and the right (or left) wheel was setup with a "ratchet gear". Basically a piece was used to keep the gear from moving backward. So when the motor ran backward the ratcheted wheel couldn't turn. The result was the robot moved forward and turned when the motor ran backward. Turning a particular direction was a the result of running the motor backward for a certain amount of time.

While GvR has a limited number of commands it does have a define command. The define command allows you to create new commands for GvR by stringing together combinations of the basic commands and those that you have defined. We will define a few new commands, including the one in Tutorial 5, and then put some of them to work.

First things first we will create a simple world file that places GvR in center of the bottom row of the map. (Note: this assumes the default window when you start GvR.) Enter the following into the world editor and save it as bottomcenter.wld:

robot 5 1 N 0

The next thing  we'll do is define the turnright command as done in tutorial 5.

define turnright:
    turnleft
    turnleft
    turnleft

Enter this into the code window. If you were to click the Execute button at this point you would get an out of instructions error with no apparent action. The system behaves the same as when there is no code in the Code Window. So let's have the robot move in a zig zag pattern. We'll incorporate the looping that we did in the last entry and have the robot move ahead a few spaces on the map. Add the following below the define statement in the code window:

do 2:
    turnleft
    move
    turnright
    move

do 2:
    turnright
    move
    turnleft
    move
turnoff

Click the reload button and then the Execute button and watch what happens. The end result is the robot 4 spaces up from where it started.facing north. Let's add another command. Add the following below the last turnleft in the definition of turnright and above the first do 2: in the command group.


define turnaround:
    turnleft
    turnleft


This command will turn the robot around so it can reverse direction. You may want to save the program at this time. Give a name you'll remember. If we Reload and Execute now nothing will have changed. We have defined the new command but we haven't used it. So add the following lines before the turnoff command:

turnaround
do 4:
    move
turnaround


Save your file again (use a different name if you want to preserve the previous program). Click Reload and the click Execute. Hopefully GvR ends up where he started. Remember that if the robot is moving to fast you can select "Set Speed" from the Setup menu and slow it down. If you want to examine what it does step by step use the Step button instead of the Execute button.

We'll define one more new command that will include one of our other new commands, to show that once you define a new command you can use it anywhere you use a built in command. Then we'll add it into our program just to make sure it works.

The new define looks like this:

define backup:
    turnaround
    move
    turnaround


It should be added to the code window after the turnaround define before the movement commands. It is important that it come after the definition of turnaround or it will generate an error.

Once you've done that add the following before the first turnaround command in the existing code.

move
backup

Save the program, Reload and Execute. 

Your final program will look like this:
define turnright:
    turnleft
    turnleft
    turnleft

define turnaround:
    turnleft
    turnleft

define backup:
    turnaround
    move
    turnaround

do 2:
    turnleft
    move
    turnright
    move

do 2:
    turnright
    move
    turnleft
    move

move
backup

turnaround
do 4:
    move
turnaround

turnoff

You might want to save a copy of the program that includes only the defines. This can be useful for adding those defines to other programs. Remember that once you close GvR or reload with a different program, those defined commands will be forgotten.

Experiment with your new commands and maybe add some more. More next time.

Saturday, January 16, 2010

Guido van Robot: Getting Started

Our first software "toy" is Guido van Robot (aka GvR). As with many of the things we'll look out on this blog let's start with a little history.

GvR is a Python implementation of Karel the Robot. Karel the Robot was originally created in 1981 by Richard Pattis to help teach students fundamental programming concepts and start them on the way to learning the Pascal programming language. The Karel concept has been adapted to many languages including C/C++, Java and our language of choice, python. To learn more about GvR's history visit the History section of the GvR website.

To learn more about the Python programming visit its home on the web at python.org. One of Python's strengths is that it has a simple syntax that makes it easy to learn. GvR implements the Karel concept using a Python like syntax. So after some time with GvR you can start to look at other tutorials on Python and have a leg up. In a later entry I'll provide some additional python resources for further exploration.

Getting GvR
You can get GvR via the download page on the GvR site. The GvR project is hosted on the open source project site sourceforge.net. Follow the link to Download GvRng. If you're using Microsoft Windows there is an installer exe file that has everything needed, including Python. If you are using Linux, the GvR site tells you that you'll need Python and PyGTK. You'll also need the python-gtksourceview package from your distribution. Once you get it installed start it up.

Building your first world
I encourage you to work with the lessons on the GvR site, which are adaptations of the original Karel exercises. We're going to combine some of the pieces in those lessons for our first set of programs.  So here comes your first bit of type in code. 

pwpTurns.wld (type into World Editor)

robot 7 3 N 0
wall 3 7 W
wall 7 7 N
wall 7 3 E
wall 3 2 N



The above code  should be typed into the World Editor tab of the GvR editor. The text is colorized to match what you'll see in GvR. The world editor sets up the map that your robot will move around on. This map consists of 4 "wall" panels and the GvR robot. The map is made up of rows and columns with the robot being placed at an intersection. (In this case the intersection of column 7 and row 3.) The direction of the robot is indicates which way it is facing. (N=up, S=Down, E=Right, W=Left) Walls start are placed on the side of the intersection indicated by the direction. We're going to get the robot to move around a little. When we're done we'll have a program that get's our robot around the map in 5 lines of code.

Step 1: Moving GvR
The first thing we're going to do is move the robot to the first red wall.

Enter the following in to the Code Editor:
move
move
move
move
turnoff

Press the Reload button
Press the Execute button

Well that was easy. The robot moves to the wall and stops. The turnoff instructions gives you a dialog box informing you that the robot has turned off.

Step 2: Getting Loopy 1
That was easy but what if we could move 4 spaces, or any number of spaces in only 2 lines of code? That would make it a lot easier. So let's change our program to what follows:

do 4:
    move
turnoff

Once you've got this in the code editor click Reload and Execute.

The result should be the same but in only 3 lines instead of the 5 lines of the first program. That's a 40% reduction in lines of code. Loops are really useful. We'll look at a different variety of loop in a couple of steps.

Speaking of steps now would be a good time to try the Step option of GvR. Reload your program and instead of pressing Execute press Step. Continue to press Step until you reach the end of the program. Stepping through a program can be useful when the program doesn't do what you want. You can watch what happens as you step through each command. As you experiment with GvR the step option will be a good way to check your programs.

Step 3: Turning GvR
The GvR robot wouldn't be much use if it could only go straight. So it has an instruction turnleft, that allows you to turn the robot. In keeping with the Karel concept of simplicity, the robot only moves forward and only turns left. While this may seem limiting it is all that is needed to get the robot anywhere you need it to go. Add the line turnleft before the turnoff command and then Reload and Execute. The program should look like this:

do 4:
    move
turnleft 
turnoff

Step 4: Going in Circles: Nested loops
One of the things you'll notice is that the move command in the loop is indented. This is a python syntax rule. So let's add an outer loop that will execute our current program 4 times. Change your program to look like what's below.

do 4:
    do 4:
        move
    turnleft 
turnoff

Click Reload and Execute. Now we have a program that does what we set out to do. Our robot goes around in a square.  One last change to the program will give you a springboard to further exploration.

Step 5: Making decisions
Our last step is to replace the inner do 4: loop with a new instruction while. The while instruction will continue to loop while the condition provided is true. In this case we will use one of the conditions that GvR understands front_is_clear. Change your program to look like this:

do 4:
    while front_is_clear:
        move
    turnleft
turnoff

What our program is going to do is move forward until it finds a wall. It will then turn left and do it again, a total of 4 times. This program could be used with a different world with the walls set at other locations as long as the path is 4 legs long.

Experiment on your own. Next time will explore the GvR concept of "beepers" and conditional statements.  

Playing with Programming?

Welcome to this new blog. The goal of Playing with Programming is to explore computers and computing with an eye to the past. The time period from 1977 to 1985 is often referred to as "The Golden Age of 8-bit Computers". Many manufacturers had success with a variety of computer designs. The following is a limited list. The links will take you to OLD-COMPUTERS.COM an on-line museum of computing history. Some of these systems I've played with, at least one I own. The first computer system I purchased was the brown plastic classic, the Commodore 64. Its still in a closet because someday I'll make it an exhibit in a small computer museum.
While I put the arbitrary date of 1985 on the end of the 8-bit era, Commodore was making and selling versions of the C-64 until 1993! The 1985 date reflects the year that both Commodore (Amiga 1000) and Atari (520 ST) introduced systems based on the 16/32-bit Motorola 68000 processor. The same chip that Apple used in the original Macintosh launched a year earlier.

But as any computer user knows, hardware is only half of the system. Software is the other half. All of these systems contained some variety of the BASIC programming language. Each one tweaked just a bit to allow access to the those features that made the computers distinctive. Some of these systems had cassette tape drives for data storage, some 5 1/4 inch floppies, some cartridge slots like the game machines of the time. (Most notably the Atari 2600) One way that you could put programs into your computer was to type them in. If you had no cartridge in the computer it would boot to BASIC and you could start typing in your program. If you did this you wanted a tape or disk drive to store your hard work. Where did the programs come from? The magazines of the time often published articles that included type in code. Computer hobbyists would by the magazines and type in the programs. In doing so they had something else to use there computer for, but also learned a little more about how the system worked. The classic magazines of the period are Byte, Compute! and Creative Computing. (Thanks to the folks at the Classic Computer Magazine Archive some of these early magazines are available on line.)

I know what you're think, "enough already with the trip down memory lane." You're right. So what will we be looking at in this blog? There are many tools that have been designed to help students learn what programming is all about. My intention in this blog is to introduce you to some of those tools and provide you with some "type in" programs. Many of the tools have a number of available type in programs created as parts of lesson plans for using the tools to teach. Links will provided for those. I'll also provide some of my own programs for you to use with full notes on what the program is doing and why. One other thing you should know as you read this. Many of these posts will be collected and edited into articles for the Twin Cities PC User Group monthly newsletter the Digital Viking.

Starting Out
The first program we will use is called Guido van Robot or GvR for short. GvR is an adaptation of the program Karel the Robot that was written in the early 1980s as a way to teach students programming with a simplified version of the Pascal language. GvR was developed in the 2000s to do the same using the Python language. Visit the history page of the GvR site for more information on its development.

Some other programs we'll play with in the future include Alice, a java based 3D environment created at Carnegie-Mellon University, and Etoys based on the Squeak language a variant of Smalltalk. We'll add to this list. As we move forward. Please feel free to suggest other tools in the comments section.

Thanks for stopping by we'll get started with GvR in the next post.