The Glamorous Toolkit: Testing a Software Exploration Tool

We’ve always been rather conservative when viewing code, data and other software structures. We’ve used file browsers, sometimes with some type of preview modes. Then we pass on code or data to another application to look at it — and then, possibly use another application to work on it.

The exploration of software has always been a bit clunky. As it is, we still use inspectors designed in the days when apps were expensive, and naturally, these became our workflow focus.

To get around this, we sometimes use platforms that can create data structures that are easier to browse. I’ve used Obsidian for some time, and this does a good job giving structure to your design ideas, creating strong documentation as a byproduct. Jupyter Notebooks allow the user to keep notes next to live code.

The Glamorous Toolkit (Gtoolkit) is written with Pharo, which seems to be a visual Smalltalk implementation. I won’t focus on these technologies in this post, but instead on the ideas the tool presents. This idea is the “moldable development environment.” To summarize this unlikely-sounding method, it is a way of bringing custom tooling to any software development problem in a timely manner.

Gtoolkit is kind of answering the question: What if an inspector or preview mode was good enough to make software exploration less clunky? For various reasons, Gtoolkit does a consistently mediocre job of describing what it actually is, but this will improve as more people look at it and a good community manager shapes the frontend for a wider audience. However, it does offer a tour, and is easy to install and play with.

At the moment Gtoolkit is tied closely Smalltalk — one of those languages that doesn’t have a lot of application but is highly respected, especially by software veterans.  In the moldable environment, Smalltalk is used to write scripts to help explore data, though I expect this could eventually be replaced by generative AI just accepting simple English descriptions. But as developers, we shouldn’t worry too much about dipping into new languages.

A Very Quick Smalltalk Explainer

To start with, everything in Gtoolkit is an object, and the only thing you do is pass messages. Let’s look at “Hello, world”:

Transcript show: 'Hello, world!'.

• Small talk is about passing messages to objects. The message show is passed to the object Transcript.
• As you can guess, the Transcript object manages the console.
• The message show has a colon followed by one argument, which is the welcoming text (or string literal) to send to the console.
• A polite full stop ends the phrase.

Molding With Gtoolkit

After installing Gtoolkit, we get a windowing interface with a list of icons on the left, and some lengthy browsable markdown documentation:

👁 Image

To get more information on the other tools, it is best to check the YouTube videos listed for good explanations unless you are already part of the Smalltalk community.

Starting with the file browser tool, you can see how you can explore within a folder, much like a Mac’s Finder:

👁 Image

Note the little blue gizmo at the top, which controls where you are in your view graph. While looking at the files, I was reminded that I did find a bug in my own project that could be solved by exploring.

After some fiddling, I got the browser to back up through the directories to look at my own code. I came to some JSON that is simply an array of small dictionaries for tying together text and icons in context for a video game narrative:

👁 Image

Earlier, I had a small bug because some of the dictionaries didn’t contain a certain key that the code depended on. So the genuine question was: How do I find the JSON objects that don’t include iconid as keys? I’m a big fan of regex, but we know not to use that in XML-like structured data because we can get lost in bracket contexts — and, as the famous answer in the link implies, might go mad in the process.

But following on from one of the introduction videos, I tried to do things the moldable way and wrote a quick query within the tool. I knew I could “monkey see, monkey do” my way by writing a small script in the page to send messages to the Smalltalk Object Notion object (STON):

👁 Image

OK, so by passing the contents of the object and then moving into the array, it gave me the list of dictionaries. With some messing about, I finally found the correct query:

👁 Image

I cobbled that final statement together quite quickly, but a short explanation might help:

• STON stands for Smalltalk Object Notation — i.e., the Smalltalk JSON library.
• the `fromString` message passes self, which is a self-reference to the caller. The object is sending itself messages.
• That phrase in square brackets is a block. It iterates over the array, looking for a specific key.
• The block is used as an argument for the reject message. That is, we don’t want the sections where iconid is used as a key.

I feel that enough of the above is present in other mainstream languages to feel reasonably meaningful.

It felt quite good using a small script to explore data profitably. While I was forced to use Smalltalk, this inconvenience could easily be soaked up by AI with a little work.

The basic ability to stay within a tool, explore your data and solve problems is one of those “ubiquitous computing” objectives that we fully expect to see in the future. While I don’t recommend that you necessarily play with Gtoolkit just yet, I think it marks a nice direction to keep an eye on.