This language was interesting to write beautifully mathematically described interactive sketch. For example a nice recursive defined construction:

(new-figure "Spirale")

(define (square p1 p2 p3 p4 n)
  (let* ((s1 (Segment "" extremities p1 p2))
         (s2 (Segment "" extremities p2 p3))
         (s3 (Segment "" extremities p3 p4))
         (s4 (Segment "" extremities p4 p1))
         (A (Point "" on-curve s1 1/10))
         (B (Point "" on-curve s2 1/10))
         (C (Point "" on-curve s3 1/10))
         (D (Point "" on-curve s4 1/10)))
     (send A masked)
     (send B masked)
     (send C masked)
     (send D masked)
     (if (> n 0)
       (square A B C D (- n 1)))))

(lets Point "M" free 5 5)
(lets Point "N" free -5 5)
(lets Point "O" free -5 -5)
(lets Point "P" free 5 -5)

(square M N O P 30)

One problem was the programming environment; indeed the user must use an external text editor and try to interpret the figure within Dr. Geo. In case something went wrong, the feedback was low and it was not possible to fix the code directly from Dr. Geo. As of today other interactive geometry software are proposing programming feature. For example, CARMetal is now proposing the Java Script language to write programmed figure with an external text editor.

I noted an additional problem: the binding between the scripting language and the language used to write the interactive geometry software prevents full transparency and inter-coupling between the internal geometric model and the effect the user wants to achieve with the scripting language.

With the new Dr. Geo II, I addressed both problems.

First, Dr. Geo II and user scripting use the same language and environment: Smalltalk. From Dr. Geo II script it is therefore trivial to use 100% of the geometric model interface. Very recently a math teacher explained me he wanted to compute the closest point on a line to an arbitrary point. When browsing the model source code directly from the Dr. Geo II application itself (with the class browser), he found out the closestPointTo: polymorphic method, and he wrote:

|figure a b d m p|
figure:=DrGeoCanvas new.
a:=figure point: (-2)@1.
b:=figure point: 3@3.
d:=figure line: a to: b.
d color: Color blue.
m:=figure point: 1@(-1).
p:=d mathItem closestPointTo: (m mathItem point).
p:=figure point: p.

Next, when writing the script, the user enjoys the full Smalltalk development machinery: class browser to write script, debugger to execute step by step faulty script, inspector to examine geometric item internal state. All the machinery is accessible directly from Dr. Geo II itself. The 11.03 release will contain in the world menu entries to these tools.

As I found out users want and can dig deeply into the Dr. Geo II model, it appeared the users want to programmatically define point whose coordinates are updated with an arbitrary piece of Smalltalk code. This idea is very neat as it push on step further the concept of user power tools. The previous code sample showed how to compute the coordinates of a closest point. Nevertheless, it is a one shot calculus, when the user modifies the resulting sketch with the mouse, the closest point is not updated any more. Therefore we need to teach Dr. Geo II how to update this point. To do so we just use block closure and we pass the block to the point definition. Each time Dr. Geo needs to update the sketch, it will execute this block of code. So if we modify just a little bit the previous example, it will look like:

|figure a b d m p|
figure:=DrGeoCanvas new.
a:=figure point: (-2)@1.
b:=figure point: 3@3.
d:=figure line: a to: b.
d color: Color blue.
m:=figure point: 1@(-1).
p:= figure 
   point: [:parents | parents first closestPointTo: parents second point]
   parents: {d . m}.

More about Dr. Geo II can be found in its documentation