Where does turtle geometry fit into the picture?

Where does turtle geometry fit into the picture?

An instance of the choice between message passing and user interfaces?

Despite my love of turtle geometry and Logo, I never added it to ToonTalk. Ten years ago I began to add it and also began user testing. The idea was that there was a bird for each turtle. If you gave the bird a box containing the text pad "FORWARD" and the number pad "100" then the bird would fly to the object and it would move forward 100 units in the direction of its current heading. Non-programming adults and a fourth-grade class seemed to really get the idea of ToonTalk (despite its primitive state) but were unhappy with the message passing interface. It was too indirect and clumsy.

I redesigned ToonTalk to support remote controls to support picture programming in a more direct intuitive manner. For example, a sensor for the horizontal position of a picture appears just as numbers do (except it has an animated marquee to indicate its special status). One can manipulate this remote control as an ordinary number and the associated picture's position changes accordingly. These work in both directions so if the picture is moved the number is updated. This scheme is similar to the property sheets used in a huge variety of software where the properties show the current state of an object and can be edited to change the object. In ToonTalk the equivalent of a property sheet is broken up into small pieces corresponding to single properties. This provides a nice "declarative" interface for objects. Children as young as six in the Playground Project made heavy use of these ToonTalk remote controls. But these remote controls only support a Cartesian geometry and don't support turtle geometry as well.

So why not add FORWARD and RIGHT sensors to ToonTalk? The equivalent of a RIGHT sensor would be straightforward; just add a sensor for the heading of a picture. The equivalent of "RIGHT 90" would be to drop a number pad with "90" on the heading sensor and the current heading will be incremented by 90 degrees. But what sensor would play the role of FORWARD? This stumped me for many years. The best idea I have is to introduce a sensor for the picture's distance to where you want it to be (in the direction of its current heading). So if you dropped 100 on such a sensor the picture would move forward correctly. The really odd thing is that this sensor would always display "0" since as soon as it is changed the picture moves and it is where you instructed it to be. Maybe a better version would be a sensor for the distance to its "goal". If its speed is infinite then it will also always display "0" but if it is given a finite speed it will glide towards it goal and the value displayed will decrement at the speed until it reaches zero. Some other design issues remain such as how to integrate the trails left by turtles' pens. Are they new objects or are they alterations of the object they are drawing onto?

I now believe that rather than choosing between message passing and user interfaces (property sheets/remote controls) that they should exist at different levels. The primitive low-level way of manipulating pictures is via message passing as I originally intended ten years ago. This will probably be used only by more advanced users, particularly those enhancing the system itself. The ideal system should provide primitive support so that remote controls can be built within the language. They would behave much as they currently do in ToonTalk but their implementation would be transparent. Ordinary users could inspect, edit, and create new kinds. The challenge here isn't just to implement sensors within the language but do so in a manner that non-experts can understand.

More generally I think a good way to proceed is to open the development of new "primitives" to a wide community. The kernel of the system can be small but include a way to "plug in" modules written in any nearly programming language. This could be based upon an improved version of ToonTalk's foreign birds. This provides a way to user birds to interface any external code. The bird or message passing level of interface can then be used to provide higher level functionality in need be.

More recently I've revisited this issue in the context of ToonTalk Reborn. Building upon browser primitives a message passing turtle can be defined. More work needs to be done to simplify its interface and add the ability to leave trails when the pen is down.