PigeonTalk Phase 2

 For many years, I've been teaching programming courses.  In order to help people visualize how object oriented programming works, I've developed an analogy.  Imagine a person sitting at a desk.  The person corresponds to an object.  In front of the person is a pile of instruction books.  There's one book for the class and one for each of its superclasses.  Also on the table is a sheet of paper where you have written down your instance variables and another ready for temporary variables.

When a message arrives, you read it and look up the instructions for the method named by the message.  You look in book for your own class first then go through the books for the superclasses until you find the method.

You then start running the instructions in the book.  When you get to a message send, you write a message to an object and send it off.  You then take a coffee break until the answer returns.

This image represents that analogy graphically.  The blue sphere on the right helps identify the kind of object.  Every class would have an icon displayed on the table.  To the left of the sphere are the books for your class and superclasses.  Below it are the instance variables and the current values.  The pink area represents temporary variables.  The green area is the message that arrived with the argument displayed.  Finally the gray area contains the code.

The code doesn't need to be represented as text.  We can use drag and drop to build the code.  The red left arrows indicate variable assignment and the up arrows represent returns.  The message in black with white text is the next message to be executed.

This is just a graphical representation of where I'm heading.  The final result may not look like this (since it was rendered in 3D with POV-Ray) but it shows what I'd like to do.

I'd like to be able to "zoom out" and see the network of objects that make up the application.  Lines would connect objects corresponding to the instance variable values.  This aspect of the system is inspired by Kent Beck's Object Explorer.  Finally, I'd like to be able to animate the execution of the program with glowing lines to show the current thread of execution.  You can watch the messages flow from object to object and return back.  You should be able to speed up or slow down the animation or pause it altogether.

The system would include breakpoints, data watchpoints (breakpoints that trigger when variables change values).  Breakpoints and watchpoints could be made conditional so they are only hit if the condition passes.

There's certainly a lot to do, but I'm moving along that path.

PigeonTalk - Phase 1

Phase 1 of the development of PigeonTalk is to create a full Smalltalk development environment.  Currently, I'm working by editing text files of Smalltalk code and using a REPL (Read Eval Print Loop) to run the commands to file in the changed files.  This is a very difficult way to develop Smalltalk code.

The REPL itself is a simple HTML / Javascript interface which establishes a WebSockets connection with the image (which may run on the same system or a different system). The VM has a Sockets interface written as VM primitives and I've written a Web Sockets interface in Smalltalk using the Sockets interface.

Using this interface, I can at least type Smalltalk commands into a Text field and have them executed then I press the Print It button.

Phase 1 improves this interface using an HTML canvas and Javascript drawing operations.  This technique is similar to the one used by Dan Ingalls in his Lively Kernel.  The difference is that Lively has you doing all of the programming in Javascript.  With PigeonTalk, the components will be implemented in PigeonTalk using Smalltalk.  The low-level drawing commands for each component will be sent using JSON to the Javascript code which interprets those commands to perform the drawing.  (A later optimization will have the Javascript code store the commands for re-drawing each component and for PigeonTalk to only send the commands to re-draw the components which have changed).

Using this technique, I plan to develop my own simple windowing system.  From there, I plan to implement workspaces, Smalltalk browsers and debuggers.  That would allow the system to behave like a real Smalltalk development environment.

Here's what the interface looks like right now.

The Do It and Print It buttons are implemented at the VM level.  The remaining buttons allow me to open the VM in a Development mode and perform single stepping and view stacks to make sure the VM is working properly.

The gray area at the bottom is an HTML canvas to use as the beginning of the windowing system. Once the windowing system works well enough, I'll remove the buttons and text fields at the top leaving only the canvas on the screen.  This will be the Smalltalk user interface.

The first version of PigeonTalk will look and feel very much like a version of Smalltalk.  Once this is working, I'll move on to Phase 2 to change the language itself.  I'll describe that vision in another blog post.

PigeonTalk

It’s been a while since I’ve posted to this blog so I thought I’d update everyone on my latest project.

First, I'd like to explain my motivation.  I started programming when I was 15 years old on my own hand-wired computer.  Over the years, I've been able to play in many areas of computing including 2D graphics, 3D graphics (including DKBTrace and POV-Ray), sound effects, music, neural networks, Braitenberg vehicles, simulated physics (ElastoLab) and computer games.  My goal is to encourage others to explore the fun areas of computing by providing a programming environment and frameworks that make those explorations easy, fun and understandable.

You may know that Simberon wrote a Smalltalk virtual machine to run VisualWorks compiled code. We used that VM to release Sea Turtle Rescue for Android and iOS.

Since then, I’ve re-written the VM to use a redesigned bytecode language. I then wrote a new Smalltalk compiler from scratch (written in itself) to compile Smalltalk source code to that new bytecode language.

This means that I now have a version of Smalltalk that runs by itself independent of any commercial software. When it’s ready, I’d like to release it as free open-source software. My working name for the project is PigeonTalk for reasons I’ll describe later.

My long-term plans for PigeonTalk fall into three phases.

1)      Create a complete self-contained Smalltalk with a development and runtime environment running in a web browser.

2)      Change the language and environment to escape the restrictions of text-based source code and compilers.  At the same time, create an environment where programming can be done primarily with drag and drop components and where the runtime operation of the code can be clearly seen.  I plan to animate the execution of the program under the control of the programmer.  A program becomes a maze that a small person runs through.  Accessing and modifying variables is represented as reading and writing things on post-it notes around the program.  Message sends are shown as carrier pigeons that fly off to deliver your message and return with an answer - hence the name PigeonTalk.

3)      Write frameworks where various kinds of applications can be easily developed on top of the framework.  For example, I'm planning to build frameworks for 2D graphics, 3D graphics, sound, music, and more.  I plan to create YouTube videos showing how to build programs on those frameworks and provide samples that others can modify.

I'm planning to fund this development with Kickstarter campaigns.  The end result will be a free product to allow as many people as possible to use it.

Coming from a Smalltalk background, I have several guiding principles:

1) All source code is visible and modifiable.  The source for the entire library is available and editable in the same development environment as you use to write your own programs.  If you're curious about how something works, just go look.  The VM is written in C and parts of the UI are controlled by JavaScript, but everything else is written in the same PigeonTalk environment.

2) The development environment is that same as the runtime environment.  You can change code even while the program is running.  The debugger allows you to stop the program, and single-step it easily seeing the effects of the code.  You can also change the code directly in the debugger and keep going.

3) Everything is an object.  Integers, Characters, Floats and Strings are objects just like the objects you create yourself.  There are no "primitive types" which are handled differently.

I'll be following up this post with more describing some of the details of this project.  If you're interested in PigeonTalk, send me an e-mail at david@simberon.com and I'd be happy to answer your questions.