XDoc

Glamorous Toolkit at strumenta.community

I had the pleasure of giving an interactive session for the strumenta.community. It was about Glamorous Toolkit, and given that the audience already had a propensity for languages, the focus was on describing how the environment too is essential for software engineering and how the environment itself can be seen as a language made out of interactive and visual operators.

Glamorous Toolkit is the moldable development environment
Glamorous Toolkit is the moldable development environment

First, let's introduce the idea of moldable development. Everything about software is data (well, objects in our case). Data is shapeless. We humans need a concrete shape to reason about data. That shape is provided by the environment. Hence the environment is essential.

Our work with Glamorous Toolkit started from rethinking the most basic tool in the environment: the Inspector. Pretty much all inspectors in the world show object as a set of variables and values, like seen below.

Generic views show everything uniformly
Generic views show everything uniformly

The view is generically applicable and through this lens all objects look the same. That is exactly what makes it less interesting. If we are to transform the inspector into a tool through which to understand an object, we need to catter for the specifics of the objects. Changing the view changes our perception.

Changing the shape of the objects changes our perception of that object
Changing the shape of the objects changes our perception of that object

Every object should be allowed to look different, and the environment should welcome the different views.

Every object can specify how it wants to be seen when being inspected
Every object can specify how it wants to be seen when being inspected

This is the essence of moldable development and the principle applies throughout the whole environment.

As an example, let's look at the visual explanation below about the making of an editor in Glamorous Toolkit. At the top of the picture we see an editor that embeds a rectangle. At the bottom we see the rendering tree that makes the editor. From the visualization we see that the rectangle is of the same kind as the rest of the elements in the tree. This explanation is shown in a scene presented as a slide in a slideshow.

Showing the rendering of a text editor interactively
Showing the rendering of a text editor interactively

Now, the same explanation can also be shown in a document. Notice how the document uses the same views but weaves them differently.

Showing the same views in a live document
Showing the same views in a live document

The interesting thing is that the views actually come from the most basic tool that exists in the environment: the Inspector.

The view in Inspector
The view in Inspector

The environment is a language through which we can combine basic pieces in many different ways to support different narratives and flows.

Let's look at one more example. On the left we see a query in a Playground. On the right, we see an Inspector on the resulting filter. The filter knows how to represent itself and offers a list of editable methods.

Querying code from Playground and writing code in Inspector
Querying code from Playground and writing code in Inspector

Through this, the Playground became a search box, and the Inspector became a place where we can write code.

For whatever reason, our industry got to believe that the work must be split across distinct tool lines. All those lines are arbitrary and and they induce unnecessary constraints. There is a systematic way to approach tool building that can help us break free of those unnecessary constraints. We call it moldable development.