Geometer Devlogs

Devlogs

• Drawing with actors
• Going to the backend: drawing with continuations
• Initial frontend

What is it?

Geometer is a drawing tool that is a hopeful successor to Ivan Sutherland's Sketchpad, my favorite program ever. It also seeks to extend of Crosscut from the Ink & Switch lab. It and is heavily influenced by Bret Victor's Drawing Dynamic Visualizations application, Seymour Papert's LOGO. The final goal is something between the Desmos graphing calculator and Lisp.

Sketchpad demonstration,
Ivan Sutherland (1963).

Geometer is supposed to offer the fewest amount of primitives to theoretically draw a dynamic image. The thought being that a simple app could be implemented as a drawing. However, the dream is that the geometer interface is implemented in itself. Unlike, Bret Victor's DDV which an incredible amount of features and details that make it a very "complete" app, Geometer should have minimal features and but maximal flexibility, allowing the user's creativity to fill in the gaps.

• Create an abstraction for emergent behaviour
• Use as few names as possible, directly manipulate data
• The app should feel like an environment, not a tool
• Reify the ladder of abstraction
• Care about performance
• Accessible to all platforms

I want to primarily investigate is how to intuitively describe emergent behavior in visual programming languages.

Who is it for?

I envision that geometer would be great for middle schoolers learning geometry. Or physics students to make small simulations. I could see it being useful for an artist/non-programmer trying to make a mini app, but it would probably feel more like a game than most apps today.

How does it work?

Since a large part of Geometer is adding constraints to drawings, it makes sense to use an actual constraint solver the way Sketchpad and Crosscut do. However, I feel that there may be behavior I want that isn't based on formal logical.

Instead, I'm trying a few more novel approaches. Most of them are based on programming language implementation. If the app is really just an interface to an internal language, I can "use the interface" by coding in that language, then gradually build the interface in itself. Like the FORTH compiler if you're familiar with that.

This means that the first step is to build a highly dynamic language. I'm currently wrestling with a few theories of what that language should look like.