Glamorous Toolkit (GT) is the Moldable Development Environment. Version 1.0 embodies more than 6 years of development and is the result of some 14 years of research. Our goal is to make systems explainable by means of custom tools created for each problem. Glamorous Toolkit makes this possible by making the creation of custom tools inexpensive and seamless.

"Ok, but what is it really? I see programming in Smalltalk. I see knowledge management. I see visualizations. But I also see that you can explore data and APIs, and you can work with other languages. So, what exactly is Glamorous Toolkit?"

Ah. Keen observations. These do not even list everything. There are significantly more things you can do with the environment. And indeed, one way to evaluate Glamorous Toolkit is through what it can visibly do out of the box. It's not our preferred way, but that's what people do regardless. So, let's get quickly through a few of those visible things.

What Glamorous Toolkit is typically perceived as

Glamorous Toolkit for Pharo development

Glamorous Toolkit is primarily implemented in Pharo and offers a complete development experience for Pharo, too. But with a few twists.

Take a look at the picture below. We see a Coder on the left hand side opened on a class with a method expanded. Inside the method we see another expanded editor for one of the messages. In the middle we see a filter tool showing the references to our method. Each of the methods can be expanded separately. One of the methods is an example, which is like a test that returns an object, a concept popularized in GT. Every example is executable and can be based on other examples. In our case, executing the example shows an inspector with the resulting object. The inspector shows a custom view.

This is a small example of a flow in GT but it already shows how rather distinct the experience is as compared with a typical Smalltalk system.

Glamorous Toolkit for system documentation

A central component in GT is Lepiter, the knowledge management system. Indeed, with it we can handle various needs. The documentation of Glamorous Toolkit itself is offered as a book inside the environment (or online). The screenshot below shows an excerpt from the book showing about the same object you see above. Only this time the result of the example is embedded in the documentation.

Indeed, each snippet is programmable and can define its own language and user interface. At the same time it's possible to link from and to arbitrary snippets.

Glamorous Toolkit for personal knowledge management

The knowledge management engine can be the entry point for all work, including for personal note taking or prototyping.

For example, here we see on the left a page from a personal knowledge base with a few snippets with text and pictures. These snippets represent the source from which I posted a BlueSky thread about Glamorous Toolkit. On the right we see another page linked from the first one which happens to be the very page from which this very post was published.

Glamorous Toolkit for browsing APIs

In a world of services, browsing associated APIs is a pervasive activity. Of course, a properly integrated experience should accommodate such a pervasive activity seamlessly. And indeed, in GT, it is quite seamless.

Here is an example of browsing BlueSky posts through the AT Protocol API. On the left we see a dedicated Lepiter snippet for logging into BlueSky. Once logged in, we get an object that shows the posts of a user. Executing a query in context gets a remote stream of posts.

The integration is seamless. All this navigation is handled through inspector extensions over domain objects that wrap the remote calls and their results. That's it.

Glamorous Toolkit for exploring data

You do not need to access data through an API to explore it. Data is data, regardless of where it comes from, and in GT you treat it equally the same.

Above we see a case of exploring the data from a social network through an API. Below we get an exploration of the downloaded data from another social network. They are treated similarly.

Glamorous Toolkit for code analysis

Everything about a software system is made out of data, including code, logs or configurations. As such, these artifacts can be manipulated as data, too.

For example, here we see on the left a query for the React components of an application. In the middle we see the dependencies between these components. Selecting a component shows it highlighted in the code to the right.

Glamorous Toolkit for domain discovery

Ok, we've a few use cases of exploring vairous data sources. But what about building new systems? It turns out that there is something in here about the discovery of new domains as well.

Take a look at this example about a restaurant automation system. On the top left we have a manual sketch about how the core of the system should work. A program produces an object that has a view showing a similar diagram, only this time produced out of the running system.

What gets people excited when looking at this? It's the idea that the system can display itself in a way that non-technical people can reason about.

Glamorous Toolkit as a graphical environment

The environment's graphical stack is another point that attracts people's attention. We understand. It's hard not to be attracted by live nested editors or visual scenes with arbitrary elements.

Consider this screenshot showing the interactive explanation of the Smalltalk syntax. It shows the typical example used to explain the Smalltalk syntax. Except that here we have a different take. There is an editor on the right with a method. On the left of it we see the list of syntax constructs. Hovering over the construct links the construct to the occurrences in the code. Live.

The above interface is possible because the whole environment in drawn in a single rendering tree at all times. For example, the words in the editor, the lines from outside the editor into the editor and the index on the right hand side are all elements that tree. This allows us to combine arbitrary visual elements creating the premise for new interfaces.

Glamorous Toolkit for GemStone development

GemStone is a Smalltalk object-oriented database. And guess what? You can interact with it from Glamorous Toolkit.

For example, here we see a couple of inspectors over remote GemStone objects related to locations and trajectories. The views in the first two panes are defined remotely as well. The map one in the third pane is retrieved on the client side by connecting to OpenStreetMap. Furthermore, in the first pane we have a script that executes remotely in GemStone, too.

Glamorous Toolkit for developing in other languages

The editing, debugging and inspecting abilities are not limited to Smalltalk languages either. Glamorous Toolkit itself is based on Rust-based plugins, so naturally we wanted to develop these plugins from the environment, too. In the screenshot below we see an environment opened on the sources of a Rust-based plugin.

Glamorous Toolkit is the Moldable Development Environment

"Aha. So Glamorous Toolkit is a collection of different tools?"

No. While all of the above perspectives describe correctly what Glamorous Toolkit can do, they are all also wrong.

Glamorous Toolkit is the Moldable Development Environment. Moldable Development is a new perspective on programming through which we create custom tools for every development problem. We find that this ability changes the very nature of programming.

Indeed, as we can only perceive details related to a software system through tools, it follows that the tools are essential to the act of programming. At the same time, because software is highly contextual, for tools to be effective they also have to be contextual.

The above examples are all quite different. In fact, each could be considered as a separate vertical in the software engineering tooling space. Yet, they were all expressed uniformly in the same environment. This shows that these tools are not distinct and that they can be combined and customized arbitrarily.

There is just a fluid environment. We do not go to tools. Tools come to us. And we can make them come to us in our terms, in our context. That's the premise of Moldable Development.

When practicing Moldable Development, we approach all problems in software development through of custom tools. This typically leads to thousands of tools per system. We created Glamorous Toolkit to evaluate how far can Moldable Development go, and we've learnt that it is applicable to all system development problems at all levels of abstraction we have encountered for more than a decade.

"All development problems at all levels of abstraction?!"

Yes, and we do mean all of them. Hard to believe, we know.

"But what do you mean exactly?"

Let's look at a couple of scenarios.

A DevOps scenario: Making sense of our build logs

We build and deploy Glamorous Toolkit on every commit using Jenkins. Like any meaningful delivery pipeline, it requires maintenance for various reasons. Often we look at the build system when errors appear. But there are other considerations as well. For example, we might want to optimize the build performance.

All these are development activities and require tools which should naturally be integrated in the development environment. Indeed, we do not go to the Jenkins interface for answering questions about our build systems. We get the Jenkins views in our environment.

Take a look below. On the left we have an inspector on an object representing a Jenkins pipeline node responsible with building a Glamorous Toolkit image from sources. The pipeline node shows the list of steps with the distinct command lines. In the middle we see the specific step concerned with loading the source code. The middle inspector shows a view with the console output. Only with a twist: The console highlights problems that are specific to Glamorous Toolkit. Let's ponder on this for a second.

The console output of a build is generic to any system. But the problems that appear in a specific system are only known in that context. Thus, if we want tools to highlight system specific-issues, we have to make them aware of the context. And that's exactly what happens here. The view encodes that context. For example, the text highligted in red shows an exception. The build is green because the exception is recoverable.

Highlighting text is nice already, but we wanted more. To the very right we see a performance report produced based on parsing the log. The view shows a flame chart with nested durations of loading different parts of the system which we used to focus on optimization opportunities.

Looking back, how would you name this tool? An API browser? A console viewer? A performance tool?

"Difficult to say... it kind of depends on the point of view?!"

Indeed, depending on the point of view all of them might fit. But those details do not matter. What matters is the experience. And this experience was put together out of a few inspectors and some views concatenated dynamically.

A debugging scenario: Identifying a text editor bug

Tools like those described here can appear attractive. Still the magic is not in their shape. The magic happens when the contextual needs drive the tool.

For quite some time we had an issue in the text editor related to the cursor getting stuck when it was at the end of a paragraph. It was annoying, but we did not know how to address it and it stayed open for half a year. That part of the code depended on Pharo objects that were wrapping Rust objects. It was only when we added the ability to inspect Rust objects that we found problem.

Take a look at the screenshot. We have a Pharo object representing a text paragraph on the left. This object wraps a Rust object. shown in the middle pane. The inspector of the Rust object shows also the list of line ranges. You can see that the first line end index is 27, and the second line start index is also 27. It took seconds to realize that a line interval cannot include both ends and from this realization came the solution.

The view that revealed the problem is not fancy. It's just a list. Still, it was exactly what we needed to identify the solution. That's where the magic lies. Of course, how tools look does matter, but it's secondary to how effective they are. And this effectiveness depends on how well they capture the context. It's this effectiveness that's at the heart of Moldable Development.

An editing scenario: Modifying baseline configurations

"Ok, so it seems that these custom tools are for reading software?"

The need of custom tooling is not only visible for reading use cases. It is meaningful for editing situations as well.

For example, the packages and project dependencies of Glamorous Toolkit are defined in so called baselines. These baselines are expressed in a fluent API through which the names of packages and projects are specified in strings. However, because of an extension that understands the semantics of the fluent API and it can offer completion inside the strings.

Furthermore, in the same way the editor offers expanders to browse the dependencies in place. For example, here we expanded the GToolkitVirtualMachine baseline to reveal the local method defining that project. Inside that method we expanded the definition of a package to reveal the details of the locally loaded package.

This editing support makes it much easier to work with elaborated baselines, as is the case with the baseline of Glamorous Toolkit itself.

Moldable Development beyond tools

The above scenarios show how changing the tool changes the problem. Indeed, Moldable Development can only be practiced through tools. Because tools are front and center in any demonstration of the approach it can be difficult at first to distinguish the concepts from their concrete incarnation.

So, instead of demonstrations, let's take a broader view using a Wardley Map.

It all starts with some challenge which can concern anything, from a narrow technical detail to a broad business concern. Regardless of the scope, every such challenge relates to a specific problem and requires a decision.

Each decision requires information. Today, much information is gathered through manual inspection and put together manually, too. Instead, we want generated views that are contextual. This can only happen through specific coding.

To make this economically viable, we need tools that can be quickly put together in context. A moldable development environment stands in contrast to the typical rigid ones in use today in that custom tools can be created quickly and during development.

"Why do you call existing tools rigid? Don't they have plugin mechanisms?"

Many environments offer some extensibility, but the emphasis is on some . There is a large difference between some problems and all problems. Moldable Development is applicable to every problem, from the narrowest technical issues, to the broadest strategic ones. As long as a decision refers to a system, it needs accurate and timely information about that system. You can get to this accurate information only by embedding the creation of tools in the development flow.

The principle is that whenever a problem is not comfortable enough, you build a tool that makes it comfortable. This can happen multiple times a day even for a single developer. To put it in perspective, in a typical IDE today, you might have dozens of extensions. When practicing Moldable Development, you can easily get to thousands of tools per system.

"Thousands of tools per system?"

Yes. These tools offer contextual views that summarize parts of the system from some perspectives. The availability of contextual views on demand changes decision making fundamentally, and with it, the very act of programming.

"But who creates all those tools?"

Moldable Development involves two distinct roles, each with its own set of skills. The facilitator (in blue on the map) is a technical role that is concerned with the technical part of building tools. But that alone is not enough. The stakeholder (in red) is at least as important. Tools are only meaningful when the relate to a question or hypothesis that is tied to value. That's the job of the stakeholder.

"And who exactly should be a stakeholder?"

Everyone with a stake in the system. From developers to board members. If they have a question concerning the system, they should have the right to be informed. Of course, the specific needs will not the same for different stakeholders. But the process to get to the answer can be. That's the magic of Moldable Development.

Glamorous Toolkit is a vehicle. Moldable Development is a journey

We can talk about the theory of Moldable Development all we want, but at the end you need to practice it to understand it. For that, you need a practical environment. That is where Glamorous Toolkit comes into play. It is the first environment in which to practice Moldable Development and us it in various practical situations, as the above examples aim to show.

But Glamorous Toolkit is also an environment in which to learn Moldable Development. You see, Glamorous Toolkit itself was created following Moldable Develpoment. It comes with thousands of little extensions and examples.

The treemap below shows all classes from Glamorous Toolkit grouped in packages. The blue rectangles denote classes that specify at least an environment extension. The green ones contain examples.

This visualization shows that the need for custom tools is pervasive. It literally touches the entire system. These are not demos. They are tools we created and used as part of our development, and they allowed us to replace reading as the main means to figure systems out, the largest cost in software development. The implications do not stop here. For example, these tools compress communication which then unlocks new ways to discover and create value.

After more than a decade of researching and practicing Moldable Development on a daily basis, we can still say that we are learning. The seamingly simple idea of customizing the tools through which to experience our systems opens up a large field with many implications. I strongly believe we are at the beginning of the journey. Glamorous Toolkit is not the end solution. It is merely the evidence that the field exists. At the same time, it is the only environment today in which to learn and practice Moldable Development.

Getting started

"It sounds great, but it also sounds like a big change compared to how we work today. That's a bit scary. How do I even get started?"

Moldable Development is best evaluated in concrete situations. That is why suggest to start the exploration with Glamorous Toolkit from a concrete problem you care about.

"Ok, what kind of problems are possible?"

The examples from this post provide some hints of what can be achieved. The case studies section from the book provide some more. The specific area of the initial problem matters less because, in the end, any situation should be addressable through custom tools. It's more important for the problem to mean something to you.

On the practical side, it is important to note that Glamorous Toolkit should be learnt more as a language rather than a tool. That is because much of the experience in the environment is made out of interactive and visual operators. Furthermore, all individual pieces area programmable and most of this programming happens in the underlying Pharo programming language. Read more practical details about Glamorous Toolkit in the book.