Girba Pitches Moldable Toolkit to Slash Developer Code-Reading Time

Tudor Gîrba - Moldable development — Curry On!

Curry On!

Because developers spend over half their time manually reading code to make decisions, engineering environments must allow programmers to generate custom visual tools in ten lines of code rather than parse raw text.

AI-assisted summary of Tudor Gîrba - Moldable development — original source. Check the original for full context.

Source published:

Key ideas

  • Developers spend at least 50% of their working hours reading code rather than writing it, making information assessment the largest and most expensive activity in software development. (0:05)
  • Glamorous Toolkit demonstrates moldable development by replacing uniform generic object inspectors with contextual, domain-specific visual views that reflect human mental models. (5:16)
  • Creating custom view extensions requires minimal overhead: across 725 active view methods in the demonstration image, each custom presentation averaged only 10 lines of actual logic. (32:34)
  • Moldable tooling drives software architecture improvements by pushing developers to reify algorithms and intermediate execution states into first-class, inspectable objects. (34:32)

Detailed notes

## Background This talk was delivered by Tudor Gîrba and published by the Curry On! channel on YouTube on July 18, 2019. The presentation runs for roughly 38 minutes, though no additional show notes or description were provided on the source page.

## TL;DR Tudor Gîrba challenges the conventional focus of software engineering on construction, arguing that developers spend over half their time reading code to make decisions—an activity he calls assessment. To overcome the stagnation of modern IDEs, he introduces moldable development through Glamorous Toolkit, where tools, object inspectors, search, and documentation adapt dynamically to human cognition and specific domain contexts. Demonstrating live custom views, ad-hoc graphing, executable documentation, and lightweight plugins, Gîrba shows that authoring domain-specific representations costs on average just ten lines of code. He concludes that because our tools shape the way we think, software systems must make tools moldable to collapse the cognitive gap between code, data, and human understanding.

## Atmosphere & style The session has the energetic, persuasive cadence of an intellectual manifesto mixed with live hacker craftsmanship. Gîrba is dynamic, candid, and deliberately provocative, frequently polling the audience, challenging their habits, and urging them to feel the cognitive shift when dry data transforms into meaningful visual forms. The audience's audible reactions and spontaneous technical questions create an intimate, workshop-like environment where radical ideas about software interaction are validated through immediate, tangible live demos.

## Bulletin - [00:05](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=5s) Developers spend at least 50% of their working hours reading code rather than writing it, making information assessment the largest and most expensive activity in software development. - [05:16](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=316s) Glamorous Toolkit demonstrates moldable development by replacing uniform generic object inspectors with contextual, domain-specific visual views that reflect human mental models. - [32:34](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1954s) Creating custom view extensions requires minimal overhead: across 725 active view methods in the demonstration image, each custom presentation averaged only 10 lines of actual logic. - [34:32](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=2072s) Moldable tooling drives software architecture improvements by pushing developers to reify algorithms and intermediate execution states into first-class, inspectable objects.

## Key takeaways - [00:05](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=5s) Modern mainstream IDEs have remained largely uniform and stagnant for decades because tool design continues to ask the same narrow questions focused exclusively on code construction. - [03:09](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=189s) Reading code is an expensive, manual decision-making strategy that must be formally recognized and treated as an explicit discipline called assessment. - [05:16](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=316s) Traditional object inspectors fail human cognition by presenting all objects as identical, generic tables of internal variables rather than domain-relevant representations. - [10:41](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=641s) An integrated development environment should function as an extensible visual language where clicking and programmatic execution are equivalent first-class operations. - [10:41](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=641s) Manual scrolling and visual scanning of structured data like JSON or XML is an unsophisticated waste of developer effort when ad-hoc programmatic querying is directly available. - [13:56](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=836s) Ad-hoc interactive visualizations built inside live inspector canvases allow developers to navigate directly into downstream target domain objects. - [13:56](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=836s) Inspectors can be extended on the fly by adding view methods with pragmas like `<gtView>` that take effect immediately without requiring tool restarts. - [18:43](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1123s) Artificial silos between file browsers, visualization tools, text editors, and query engines can be dismantled when custom views are treated as standard source code tracked in version control. - [21:43](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1303s) Providing dual perspectives—technical raw data alongside human-readable domain views—bridges communication gaps between programmers and non-technical stakeholders. - [24:14](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1454s) Static documentation rots, but live executable storytelling documents eliminate manual code duplication while visually communicating human rationale and design decisions. - [30:36](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1836s) System search can be moldable and scoped, adapting dynamically to the specific object context rather than overwhelming developers with monolithic global search results. - [32:34](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1954s) The marginal cost of building custom plugins is negligible in a moldable system, enabling hundreds of lightweight domain-specific views to coexist seamlessly in one IDE. - [32:34](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1954s) Echoing Marshall McLuhan's warning that tools shape the human mind, software engineers must recognize that rigid tooling dictates how they think about software architecture. - [34:32](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=2072s) Difficulty in visualizing or explaining an algorithm indicates missing design abstractions, prompting developers to reify intermediate steps into first-class objects.

## Detailed walkthrough ### [00:05](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=5s) The Stagnation of IDEs and the Real Nature of Software Engineering

The session opens with the host inviting the audience to interrupt with questions at any point during the talk. Taking the stage, Tudor Gîrba warms up the crowd and sets out his ambitious premise: he is here to sell the audience on the idea that tools are foundational to software engineering and that they must become moldable. He invites them to engage deeply, be as skeptical as possible, and challenge him vigorously. Introducing his background, Gîrba notes that he co-founded feenk, a consulting company whose ultimate objective is not merely software consulting, but transforming the development experience—an experience that he insists must encompass everyone working with a software system, not just programmers.

Gîrba points out that our conversations about the development experience inevitably center around the Integrated Development Environment (IDE). Flipping through slides showing screenshots of multiple mainstream modern IDEs, he observes how strikingly uniform they are: if you squint from afar, it is virtually impossible to tell them apart. This prompts a fundamental design critique: is this uniformity proof that we have reached the pinnacle of design, or have development tools failed to evolve over the last twenty years because we keep asking the exact same questions? Gîrba asserts that the latter is true, and that breaking out of this evolutionary rut requires fundamentally reframing what software engineering actually is.

When industry professionals speak of "development environments," they almost universally focus on construction—the empowering sensation of creating something out of nothing. As Gîrba puts it: “I mean whenever we talk about development we think about the construction part, the empowering part that is: I don't have it, I develop it, and then I have it, right?” Yet, empirical studies and his own conversations with roughly 3,000 developers reveal a starkly different reality: developers spend 50% or more of their total time reading code rather than writing it.

```mermaid flowchart TD accTitle: The Reality of Developer Time Allocation accDescr: Diagram contrasting the perceived activity of construction with the actual primary activity of code reading and assessment.

subgraph Perceived["Perceived Activity"] Const["Construction & Coding<br/>('Empowering creation')"] end

subgraph Actual["Actual Activity (>50% of Time)"] Read["Reading Code"] Assess["Assessment & Decision Making<br/>(Extracting information to act)"] Read -->|"Most manual strategy"| Assess end

Perceived -.->|"Overshadows"| Actual ```

[03:09](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=189s) Assessment: Reframing Reading as Manual Decision-Making

To emphasize the disconnect in the industry, Gîrba asks audience members who agree that developers spend over half their time reading code to raise their hands—and then asks those who regularly hear developers talk about *how* they read code to keep their hands up. Predictably, almost every hand in the room drops. Reading code represents the single largest, most expensive activity in software engineering, yet it is almost never treated as an explicit topic of engineering discussion.

Gîrba deconstructs why developers read code in the first place: they read in order to understand what to do next and to make informed choices. The fundamental activity is not reading itself, but decision-making. Viewed this way, reading text is simply one specific strategy for extracting information from data to inform decisions—and it happens to be the slowest, most manual strategy available. To shift the paradigm from manual labor to intentional engineering, Gîrba argues that we must give this practice a dedicated name: *assessment*.

> “Perhaps, given that this takes most of our time, perhaps it's actually useful to start regarding software engineering as being, you know, less of a construction business and more of a decision-making business.”

- Developers spend 50% or more of their working hours reading source code. - Gîrba has validated this figure through direct conversations with approximately 3,000 software developers. - Despite reading code being the single largest expense in software development, teams rarely discuss reading strategies or methodologies. - Naming the practice *assessment* elevates decision-making and information extraction into an explicit, improvable engineering discipline.

[05:16](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=316s) Rethinking the Object Inspector with Glamorous Toolkit

To demonstrate how tooling can support assessment instead of passive reading, Gîrba introduces Glamorous Toolkit, a moldable development environment constructed in Pharo (a modern Smalltalk system). Glamorous Toolkit replaces the traditional Smalltalk interface with an entirely new graphical stack designed to foster novel workflows. Rather than focusing on how systems are constructed from scratch, Gîrba turns his attention to how developers inspect and reason about existing software systems. In an object-oriented paradigm, the smallest fundamental unit—the metaphorical biological cell—is the object.

In traditional IDE debuggers and inspectors, every object is rendered identically as a generic list of internal variables and raw values. Gîrba displays six side-by-side standard inspector panes showing six different objects; each one looks like an identical, dry two-column table. While accurate about the object’s internal memory representation, this view fails to convey what the object actually *means* or how a human brain processes it. Gîrba then switches the display to show domain-specific, visual views for each of the six objects:

1. A fraction displayed as formatted mathematical notation. 2. A color rendered as a physical color swatch. 3. A file folder displaying its filesystem hierarchy and file contents. 4. An image object showing the rendered graphical picture. 5. A geometric neighborhood algorithm rendered as a visual neighborhood circle graph. 6. A text string rendered to expose its underlying rope data structure tree.

When the switch occurs, the audience reacts visibly. Gîrba pounces on the moment: “Did you feel something here? Not seriously, did you feel something? It's the same thing, right? It's really literally exactly the same object... Do you feel how your brain completely changes how it engages with that?” By molding the visual shape of an object to fit human cognition, the developer's ability to reason about the system is transformed.

An audience member chimes in to ask why the string object is visualized as a branching tree. Gîrba clarifies that the editor represents text internally using a rope data structure. In Glamorous Toolkit, a developer can seamlessly flip between different contextual perspectives of that single entity: view it as rendered rich text, inspect the raw underlying character string, or examine the binary tree nodes of the rope data structure itself.

```mermaid flowchart LR accTitle: Multiple Inspector Perspectives on an Object accDescr: A single object yielding different contextual views inside the Glamorous Toolkit inspector.

Obj["Single Object<br/>(e.g., Text Rope / Folder / Color)"]

subgraph Views["Contextual Perspectives"] V1["Raw Internals<br/>(Variables & Values)"] V2["Domain Rendering<br/>(Visualized Swatch / Tree / Math)"] V3["Interactive Structure<br/>(Navigable Filesystem / Nodes)"] end

Obj --> V1 Obj --> V2 Obj --> V3 ```

[09:43](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=583s) Interactive Exploration in the Playground

Gîrba transitions from static examples to a live interactive demonstration using the Glamorous Toolkit *Playground*. The Playground serves as an exploratory workspace where code can be evaluated interactively and connected directly to downstream inspection views. To illustrate, he evaluates an expression referencing his local directory in the filesystem:

> “So now what do I see here? Instead of seeing this, which is again, this is accurate, it's a completely an accurate description of what is inside that object, but this is useful.”

Rather than confronting the user with an internal heap-dump listing raw pointer references, file descriptors, or internal byte offsets, the resulting inspector pane displays a purposeful file-system navigation view. This highlights the three foundational pillars of the Glamorous Toolkit inspector architecture: - **Multiple contextual views:** Every single object can project multiple distinct views depending on the specific questions the developer wants to answer. - **Side-by-side object chaining:** Executing an expression or selecting a child element immediately spawns the resulting object into a connected pane to the right, creating a continuous, navigable trail of thought. - **Actionable domain utility:** Views prioritize domain utility and cognitive alignment over pure internal implementation details.

[10:41](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=641s) The IDE as an Extensible Visual Language

Tudor Gîrba demonstrates how navigating an object graph through visual interactions and executing code are fundamentally equivalent actions within Glamorous Toolkit. Clicking on an item to dive into it is not distinct from executing an expression in code; the boundaries between traditional user interface interactions and programming dissolve. Instead of treating the integrated development environment as an inert collection of features, Gîrba introduces a core design philosophy: “In fact we look at the IDE as a language, not an IDE as a set of features, but as a language—a language made of visual and interactive operators that basically can extend the host language.”

```mermaid flowchart TD accTitle: Unified Flow of IDE Navigation and Code accDescr: Diagram illustrating how visual interaction and code execution blend seamlessly within the inspector environment.

subgraph Interaction["Unified Modality"] A["Click / Visual Navigation"] <-->|"Equivalent"| B["Code Execution in Playground"] end

subgraph Inspection["Host Object Environment"] B --> C["Inspector Context (`self`)"] C --> D["Custom Live Views & Embedded Editors"] end ```

To illustrate this fluidity, Gîrba inspects a JSON file. Rather than presenting the file merely as raw text, the inspector exposes a JSON-aware view with an inline editor where changes can be made immediately. When looking at an embedded JSON array, the user might want to know how many elements it holds. While one could manually scroll down the file to count them, Gîrba rejects that instinct outright: “I could potentially go and scroll here, right? I could do that, but this would imply now that I'm gonna read my way to finding out this answer, and that's a highly unsophisticated—is it a highly manual way, and we should go away from doing that.”

Because JSON is structured data rather than raw text, the developer can open an ad-hoc playground directly on the file object, where `self` represents the file target (similar to a live Smalltalk REPL). By writing `STONJSON fromString: self contents`, the string is parsed into an in-memory object on the spot, instantly revealing that there are exactly nine items. Navigating through the resulting objects proceeds seamlessly from UI to code and back again. Furthermore, once an operation like parsing JSON becomes a common need, it can be surfaced directly in the UI as an icon, letting the environment grow organically alongside the programmer's habits.

- Navigation through clicking and navigation through running code are treated as identical, first-class operations. - The inspector is redefined from being the simplest, lowest-level inspection tool into a fully editable, programmable environment. - Manual reading and scrolling of structured artifacts is framed as a waste of developer effort when programmatic querying is instantly accessible.

---

[13:56](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=836s) Interactive Graphing and Extending Tools on the Fly

Gîrba moves to inspecting a collection of folders to understand their hierarchical depth. Instead of navigating each folder manually or leaving the environment to run an external visualization script, he scripts an ad-hoc graph visualization right inside the inspector playground. He queries the directory structure for its nodes (`allDirectories`), sets up edges connecting each directory to its parent, and applies a tree layout.

The resulting visual hierarchy is not a static picture or an exported dead-end image; it remains a live Smalltalk canvas where clicking on any node immediately navigates directly to that folder's inspector.

```mermaid flowchart LR accTitle: Ad-Hoc Visualization Pipeline accDescr: Pipeline showing the quick steps to build an interactive directory tree visualization inside the inspector.

subgraph BuildVisual["Inspector Playground"] N["Query Nodes: allDirectories"] --> E["Map Edges: parent relation"] E --> L["Apply Tree Layout"] end

BuildVisual --> O["Live Graph View"] O -->|"Click Node"| Nav["Dive into Folder Inspector"] ```

He then inspects an XML file cataloging books by author and title. While XML may not be universally beloved—Gîrba polls the room on who dislikes it to a wave of knowing laughs—it remains a structured tree and deserves to be manipulated as such. To extract author tags without clicking through nested tree nodes, an XPath query is the obvious solution (`self xpath: '//author'`), returning 12 author elements.

However, because querying an XPath requires an arbitrary input string, it cannot be modeled as a simple unary action button. Gîrba shows how to alter the tool itself in real time:

- He clicks over to the **Meta** tab, which embeds a live source code browser targeting the class of the object currently being inspected (`XMLNode`). - He locates the method `gtXPathFor:` which defines how an XPath query presentation is constructed with a text editor and an action button. - By adding the appropriate view annotation (such as `<gtView>`) and saving the method, a brand-new tab appears immediately in the active inspector without needing to reload or restart. - Entering `//author` into the new input field evaluates the expression and directly returns the target elements.

Gîrba emphasizes the significance of this rapid customization: “What just happened here: while I was working with the tool, I noticed that I want to extend the tool, and I take a little few minutes, and then I extend that tool and I continue, because the way we look—the way objects and everything around our software system, the way those look, they determine the way we're going to think about them, and that's the premise of moldable development.”

---

[18:43](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1123s) Dismantling Tool Silos and Versioning Custom Views

Stepping back from the demo, Gîrba challenges the audience to classify the interface they have just witnessed: is it a file browser, a visualization tool, a text editor, or a query engine? It encompasses all of them at once. He argues that the rigid boundaries dividing modern developer tools are artificial: “Tool silos are just an arbitrary artifact that were produced by, you know, essentially by tool vendors, and I think that's a wrong way to look at this problem.”

An audience member asks how extensions made directly in the live environment can be shared across a wider team and whether partial changes can be reviewed or rejected. Gîrba clarifies that because Glamorous Toolkit is fundamentally a code-centric Smalltalk environment, view extension methods are standard source code:

- The newly authored presentation methods live in the system packages alongside standard domain code. - Developers commit them to Git just like any other feature, library, or test. - When team members pull the code or CI constructs the next build, the custom views and inspectors assemble automatically into their environments.

---

[19:52](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1192s) Real-World Case Study: PolyPedia and GDPR Data Pods

Gîrba transitions from technical demonstrations to real-world deployment, noting that moldable development is not merely an academic theory. His team has been refining the practice for five years, building across four years on what is now the second generation of the Glamorous Toolkit. To showcase its efficacy, he introduces their work with **polyPOP**, a company focused on helping end users reclaim control over their personal digital footprints.

Under modern data privacy regulations like Europe's GDPR, online platforms are legally mandated to allow users to export the personal data collected about them. In polyPOP's architecture, this scattered data is downloaded and consolidated into a local **pod** that resides directly on the user's personal machine. Gîrba inspects a live pod object containing exports across multiple platforms:

- A personal LinkedIn account (`tgirba`) - The company Twitter account (`feenkcom`) - A personal Twitter profile - A Facebook data archive

When raw platform exports are opened, they consist of dense, cryptic files and unstructured bundles. However, using moldable development, custom views inspect the pod to render a familiar, high-fidelity experience—such as turning a raw Twitter data export directly into an interactive, readable feed layout that mirrors Twitter itself, bridging the gap between raw machine data and human comprehension.

[21:43](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1303s) Introspecting Raw Data and Bridging Developer Perspectives

Examining a real-world Twitter data dump, Tudor Gîrba demonstrates that while the export complies with regulations, it delivers JSON wrapped inside JavaScript that is practically unreadable for a human brain. To make sense of it, the environment translates the payload into an interactive, intuitive representation. This rapid alternation between technical details and higher-level user views is essential, because software development constantly requires developers to jump meta-levels on the fly. By surfacing views that a non-technical end user can intuitively understand alongside raw structural data, the tooling collapses the traditional gap between programmers and stakeholders.

```mermaid flowchart LR accTitle: Introspection and Perspective Transformation accDescr: Raw payload transforms into both technical inspector data and domain-level user presentations. subgraph S1["Raw Ingestion"] A["JSON inside JS Payload"] end subgraph S2["Transformation"] B["Translator / Engine"] end subgraph S3["Dual Perspectives"] C["Low-Level Technical Data"] D["Human-Readable User View"] end A --> B B --> C B --> D ```

Misunderstandings in software projects regularly arise from misaligned vantage points. When those diverse perspectives are surfaced inside the same tool, team conversations fundamentally change. Gîrba emphasizes that in this moldable workflow, developers spend the overwhelming majority of their time inside the inspector rather than in static source code browsers or debuggers, because the inspector guarantees the constant presence of `self`.

- “Because it is not understandable for us either, we translate it, all right, so again it's the same thing but now you look at it differently and so this ability to introspect and go quickly and then change the perspective is super important.” - “Communication problems will come or are generated because of the differences in perspectives, but if we make those perspectives apparent, the conversation completely changes.” - “We're spending the largest majority of the time, the development time, in the inspector and not in the code browser.”

[24:14](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1454s) Live Storytelling and Whiteboard Representations in Documents

Broadening the concept of integration, Gîrba turns to bridging technical teams and business domain experts through a live document engine. The environment uses a custom markup language where formatting syntax disappears naturally as the author types, eliminating a jarring modal "edit mode." Rather than treating documentation as static text, it serves as an interactive canvas. By evaluating code directly within the document, he constructs an example of price calculations: a base price of €100 wrapped in a €10 money discount decorator, which is then wrapped in a 10% discount decorator to yield €81.

```mermaid flowchart TD accTitle: Discount Decorator Architecture accDescr: Base price flows through sequential discount decorators to produce the final price. subgraph Prices["Price Calculation Pipeline"] P1["Base Price: €100"] P2["Discount Decorator (-€10) = €90"] P3["Percentage Decorator (-10%) = €81"] P1 --> P2 P2 --> P3 end ```

While code states cold facts, it cannot communicate human reasoning or design rationale. Gîrba argues that cultures share knowledge through storytelling, and development environments should serve as platforms for narrative. Navigating this decorator chain step-by-step through standard object properties causes the reader to lose the broader mental model. To fix this, the team built a custom visual presentation that mirrors the precise diagram domain experts drew on a whiteboard: a clear visual breakdown showing €81 as 10% off €90, which in turn is €100 minus €10.

- “Software, like the only truth, the main truth is in the code, but the code shows you facts, it doesn't tell you reasons, it doesn't tell you why it is like that, and why it is like that, why something, or anything is the way we share it as a, you know, through our culture is through narratives: you want to tell stories about the kinds, about the things that are less easy to understand.” - “Once a human deems a representation of a fact as meaningful, it's the responsibility of the system to carry it forward.”

[28:14](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1694s) Executable Examples and Interactive Workflow Documentation

To prevent documentation from rotting, Gîrba avoids pasting raw code snippets directly into documents. Instead, the documentation engine links to live, executable examples that function like tests returning concrete domain objects. Authors can embed code snippets into the text without manual copy-pasting, execute them dynamically, or strip away the technical code entirely to present only a clean, live preview tab (such as an overview widget) for business stakeholders.

He showcases an actual production system documented with this engine, featuring a restaurant workflow set in a "cozy corner" with a kitchen, a guest room, and actor models. Within the prose document, readers can interact with live checklist items: checking an order placed by a customer named Alice immediately triggers actor messages that visibly flow down the pipeline to the cook.

- “I don't want to write any code into my, into my documentation, because then I have to deal with this idea of how do I synchronize the code between the real code and documentation, and so there's a whole set of problems.” - “As I move away, I'm left with the live document, right, it's just a document that has no technical detail, I can just ship to non-technical people, and what is interesting about this is the cost of this document on top of, after that, if the normal development, is very, very small.”

[30:36](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1836s) Moldable, Context-Sensitive Search

Moldability extends beyond views into system search. Rather than relying on a monolithic search bar that yields overwhelming global results, objects define their own contextual search capabilities. Searching for a common method like `do` globally returns a massive list of implementers across the entire image. However, when the user navigates into the `Collection` class, the search instantly adapts to that specific scope, restricting matches strictly to methods defined within collection classes.

```mermaid flowchart TD accTitle: Scoped Search Hierarchy accDescr: Search queries change scope based on the active object context. subgraph Global["Global Context"] G1["Query: 'do'"] --> G2["All system implementers"] end subgraph ClassScope["Collection Class Context"] C1["Query: 'do'"] --> C2["Collection-only methods"] end subgraph AccountScope["Account Context"] A1["Query: 'GT6'"] --> A2["Account-specific posts"] end ```

Gîrba shows that this principle applies identically to domain-level entities. In a multi-account social media aggregation tool, querying `GT6` from the root searches across all configured feeds (such as Twitter accounts and personal feeds). Diving into a specific account node immediately narrows subsequent queries exclusively to that account's timeline.

- “The idea here is that not only does an object know how to present itself in many ways, it also knows how to search, it's how to get searched.” - “The search is also scoped, and it's very simple, it's what is interesting here is that these are just some examples, right, they didn't handpick, I mean I hand-picked those, but out of many.”

[32:34](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1954s) The Economics of Plugins and Marshall McLuhan's Warning

Tudor Gîrba inspects the implementation of the custom view he demonstrated earlier. In Glamorous Toolkit, these custom presentations are defined simply as methods annotated with the `<gtView>` pragma. To illustrate how pervasive and lightweight this mechanism is, he queries the running environment for all occurrences of `#gtView` pragmas. The search returns a browser listing 725 such methods across the image.

```mermaid flowchart LR accTitle: Custom View Economics in Glamorous Toolkit accDescr: Diagram showing how 725 custom view plugins average only 10 lines of actual code each.

subgraph Metrics ["View Economics"] A["725 gtView Pragmas"] --> B["~8,700 Lines of Code"] B --> C["~12 Lines per Method"] C --> D["10 Lines of Real Logic<br/>(Excl. Pragma & Signature)"] end ```

Running a quick calculation on the total code volume reveals around 8,700 lines of code across all these views, averaging roughly 12 lines of code per method. Once subtracting the method signature and the pragma annotation line itself, each custom inspector view requires just 10 lines of actual logic. Gîrba emphasizes that this represents the real marginal cost of building an extension: in effect, he has over 700 custom plugins coexisting smoothly in the same IDE during the demo.

Gîrba concludes his talk with a philosophical reminder about technology and human cognition, invoking media theorist Marshall McLuhan and his student John M. Culkin:

> “We shape our tools and thereafter our tools shape us.”

Because our development environments fundamentally dictate how developers think and approach software construction, engineers must remain vigilant about the properties of the tools they adopt. As Gîrba puts it:

> “Tools are essential in software engineering and they should be moldable.”

- A search for the `#gtView` annotation (pragma) yields 725 custom presentations currently active in the running environment. - The total size across all 725 methods is approximately 8,700 lines of code. - With an average method size of 12 lines (including one line for signature and one for the pragma), a fully functional domain-specific view plugin costs only 10 lines of executable code.

---

[34:32](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=2072s) Q&A: Decoupling Interactions from the Language and Explaining Algorithms

During the question-and-answer period, an attendee asks whether this interactive paradigm can be isolated from the underlying Smalltalk/Pharo platform so developers could experience the same workflows across multiple programming languages. Gîrba confirms that Glamorous Toolkit is conceived as an extensible platform rather than a single-language IDE. It already incorporates a multi-language software analysis platform and extensive parsing frameworks (such as SmaCC), with explicit plans to support other languages directly.

Another audience member points out that while Glamorous Toolkit clearly visualizes static data and domain objects, developers spending time reading code frequently need to understand execution processes and algorithms. Gîrba explains that moldable development alters how engineers write software by introducing a tight feedback loop between the tool and the code design:

> “The interesting thing here is that when we work and we have a problem we don’t just solve the problem we don’t just write a test and solve the problem we build the tools write the tests and solve the problem.”

When an algorithm is difficult to explain or visualize within a tool, it usually signals that the steps or execution flow are not reified. To resolve this, developers decompose the algorithm and turn intermediate states or execution steps into first-class objects—often applying functional decomposition principles within an object-oriented codebase. Gîrba references the earlier messaging workflow demo, where a message and its routing across actors were made first-class entities precisely so the algorithm's propagation could be inspected and reasoned about interactively.

- Of the roughly 725 views present in Gîrba's working image, approximately 400 ship as generic or baseline views in the default Glamorous Toolkit distribution, meaning roughly 250 to 300 views were created specifically for that demo system. - Designing domain-specific views often drives architectural improvements, pushing developers to reify algorithms and execution steps as first-class objects rather than keeping them hidden in opaque procedural code.

## Notable quotes > [32:34](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1954s) Tools are essential in software engineering and they should be moldable. — Tudor Gîrba

> [03:09](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=189s) it's actually useful to start regarding software engineering as being, you know, less of a construction business and more of a decision-making business. — Tudor Gîrba

> [24:14](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1454s) Once a human deems a representation of a fact as meaningful, it's the responsibility of the system to carry it forward. — Tudor Gîrba

> [21:43](https://www.youtube.com/watch?v=Pot9GnHFOVU&t=1303s) Communication problems will come or are generated because of the differences in perspectives, but if we make those perspectives apparent, the conversation completely changes. — Tudor Gîrba

## Mentioned Tudor Gîrba, feenk, Glamorous Toolkit, Pharo, Smalltalk, polyPOP, LinkedIn, Twitter, Facebook, Marshall McLuhan, John M. Culkin, SmaCC

[Source](https://www.youtube.com/watch?v=Pot9GnHFOVU)

中文简报

吉尔巴推介可塑工具包,大幅缩减开发者读代码时间 由于开发者超过一半的时间都花在手动阅读代码以进行决策上,工程环境必须允许程序员仅用十行代码即可生成自定义可视化工具,而非费力解析原始文本。 都铎·吉尔巴(Tudor Gîrba)对软件工程传统上专注于构建的观点提出挑战,认为开发者超过一半的时间都花在阅读代码以做出决策上——他将这一活动称为评估。为了突破现代 IDE 的停滞状态,他通过 Glamorous Toolkit 引入了可塑开发(moldable development),使工具、对象检查器、搜索和文档能够动态适应人类认知和特定的领域上下文。吉尔巴现场演示了自定义视图、即席绘图、可执行文档和轻量级插件,展示了编写领域特定表示形式平均仅需十行代码。他总结道,由于我们的工具有形塑造着我们的思维方式,软件系统必须让工具具备可塑性,以消除代码、数据与人类理解之间的认知鸿沟。 开发者至少有 50% 的工作时间花在阅读代码而非编写代码上,这使得信息评估成为软件开发中耗时最多且成本最高的活动。 (0:05) Glamorous Toolkit 展示了可塑开发理念,它用反映人类心理模型的上下文相关、领域特定可视化视图,取代了统一通用的对象检查器。 (5:16) 创建自定义视图扩展所需的开销极小:在演示镜像中的 725 个活动视图方法中,每个自定义展现形式平均仅包含 10 行实际逻辑。 (32:34) 可塑工具通过促使开发者将算法和中间执行状态具体化为头等、可检查的对象,从而推动软件架构的改进。 (34:32)

Source quotes

[32:34] Tudor Gîrba: Tools are essential in software engineering and they should be moldable. [3:09] Tudor Gîrba: it's actually useful to start regarding software engineering as being, you know, less of a construction business and more of a decision-making business. [24:14] Tudor Gîrba: Once a human deems a representation of a fact as meaningful, it's the responsibility of the system to carry it forward. [21:43] Tudor Gîrba: Communication problems will come or are generated because of the differences in perspectives, but if we make those perspectives apparent, the conversation completely changes.

Original transcript

[0:05] if you have any questions he is welcome [0:08] to hear your questions during the talk [0:10] so you don't have to wait but because [0:12] it's recorded raise your hand and I'll [0:14] bring the microphone to you hello [0:18] everyone [0:22] one more time hello everyone and what's [0:26] better enjoying the conference excellent [0:29] so here's the thing today I want to sell [0:31] you on an idea and the idea that tools [0:36] are essentially software engineering and [0:37] that they should be moldable well I will [0:40] be demonstrating what that means but I [0:42] would like you to engage with me if [0:43] possible I want you to be acceptable as [0:46] you can and challenge me as hard as you [0:48] can is that ok ok good so my name is [0:53] tutor girl but I work at think that's a [0:56] company that I co-founded it's a [0:59] consulting company but our real goal is [1:01] to change the development experience [1:04] that is the experience that people have [1:06] when they work with software systems [1:09] notice how I don't necessarily say [1:11] developers because I think that [1:13] everybody that works with the software [1:15] system should be integrated there and so [1:17] when we talk about the experience we [1:19] talk about an IDE right and so this is a [1:21] typical kind of an IDE all right anybody [1:25] familiar with that good right so so this [1:29] is one of those and here's another one [1:32] and what's interesting about them is [1:34] that it's hard to this to distinguish [1:37] between them right if you squint from [1:39] afar it's it's not really easy they're [1:41] very much similar and here's maybe [1:43] another one so the question here is is [1:46] this the pinnacle of design and if not [1:49] why did we not evolve over the last 20 [1:52] years and so is it possible that may [1:55] perhaps we're asking always the same [1:58] question and that prevents us from [1:59] evolving so I'm gonna suggest that this [2:02] is true so again before we dive into the [2:06] actual new proposition [2:09] I would like to frame the problems like [2:10] the different thing so here's the thing [2:12] all of those tools they they are called [2:17] development environment I mean whenever [2:19] we talk about development we think about [2:22] the construction part the empowering [2:24] part that is I don't have it I develop [2:26] it and then I have it right it's very [2:29] empowering and this is amazing because [2:31] like we're developers and we're just [2:32] everything around us gets completely [2:35] reshaped because of us so that's an [2:39] amazing thing and an amazing thing to [2:41] think about but at the same time if you [2:43] look closely at what developers do you [2:46] know developers actually don't develop [2:48] most of the time that's an interesting [2:52] thing so for a lot of the time 50% or [2:55] more according to different studies and [2:57] from my conversations with about 3,000 [3:00] developers so far developers spend 50% [3:03] or more of their time reading code would [3:06] you agree with this right now here's the [3:09] here's the other thing but just could [3:12] you keep your hand up please if you [3:14] agree with this so if you do agree with [3:17] this right this is 50% or more of the [3:20] time this is the largest most expensive [3:21] activity we have so when was the last [3:24] time you heard developers talk about how [3:25] they read code right it's amazing right [3:30] very few are still here right even if [3:32] you did hear them keep your hand up if [3:35] you've heard of like a very regular [3:37] conversation or did it just happen last [3:39] year or half a year ago it's not a [3:41] subject of conversation right so few [3:43] hands are which is great but in general [3:46] it is not a subject conversation thank [3:49] you so that's was the this was your [3:51] sports for today so what is the problem [3:56] of this well again this is the single [3:58] largest expense we have and nobody talks [4:01] about it and I think we should now if [4:04] you do talk about it then in fact most [4:07] of the time they really you know the [4:09] reason developers read code is because [4:10] they want to understand what to do next [4:12] right they want to understand how do you [4:15] know what code to make a decision [4:17] it's called decision making so the [4:20] activity is actually not reading the [4:22] activity is decision making so perhaps [4:25] given that this takes most of our time [4:26] perhaps it's actually useful to start [4:29] regarding software engineering as being [4:31] you know less of a construction business [4:33] and more of a decision-making business [4:35] and so if reading is the strategy then [4:39] perhaps there are other strategies right [4:41] because it's a strength this would be [4:42] the strategy with which you extract data [4:45] or sorry information out of data because [4:47] that's what you need to make decisions [4:48] it so happens that reading is actually [4:51] the most manual possible way in which [4:53] you can do that right so then why are we [4:56] not constructing a different perspective [4:57] on this given again this is the largest [4:59] expense so the first thing we should do [5:01] every time we want to talk about [5:02] something is we have to give it a name [5:04] so I call it assessment and that's I [5:08] think that's a core activity in software [5:10] engineering and we should actually [5:11] explicitly talk about it and learn from [5:13] each other in doing that ok so that's [5:16] the perspective from which I want you I [5:19] want you to looking at the two demos [5:21] that I will be giving you so I'll be [5:23] showing you glamorous toolkit that's a [5:25] new kind of a development environment [5:27] which we call it's a moldable [5:28] development environment and I'll explain [5:30] what that is um [5:32] glamorous toolkit is an environment that [5:35] is built in thorough and at the moment [5:37] works for faro anybody knows what far [5:39] away's Wow how surprising mom so far Oh [5:42] for those that don't Farrow is a [5:45] beautiful object-oriented language is a [5:47] small talk system and it comes with its [5:50] own environment the language plus the [5:51] environment and what grammars toolkit is [5:53] is a replacement of the environment it's [5:55] a complete new graphical stack with [5:56] complete new kinds of properties inside [5:58] it enables new workflows so as I said I [6:03] don't want to focus so much on how we [6:04] construct systems and much more than [6:06] tall spend the time today to look at how [6:09] we reason about the existing systems and [6:11] in order to change bigger you know [6:13] bigger patterns if we I want to start [6:16] from the cell so given the first opal in [6:19] this case we are looking at an [6:20] object-oriented system but also in other [6:22] cases the smallest possible thing that's [6:24] most basic thing that we have is perhaps [6:27] not computation but data right and in [6:30] this case in an object-oriented system [6:31] it would be an object so if you look at [6:36] a typical IDE and how objects are [6:39] represented so when you open an [6:40] inspector for example you see something [6:42] like this [6:43] right so here I have six different [6:45] inspectors showing you six different [6:48] objects and when you see right they're [6:51] all representing the same way variable [6:52] and value right that's a that's a [6:55] reasonable way to look at this right but [6:58] it's only reasonable if if the thing [7:01] that we want be expected to be is to to [7:04] be something that shows accurately the [7:06] interior of that object but most of the [7:09] time when we want to work with an object [7:10] we don't necessarily care how it is [7:13] represented internally we care about [7:15] what it means for us it's a different [7:18] perspective so what if I take those [7:21] things that you know this representation [7:23] works equally well for all objects [7:25] that's why all inspectors in the world [7:26] basically show it the problem is that [7:29] most inspectors in the world today and [7:31] stop there but let's imagine I have [7:34] these objects and I change it like this [7:36] how does that make you feel did you feel [7:40] something here not seriously did you [7:42] feel something it's the same thing right [7:45] it's really literally exactly the same [7:47] object these two are the same objects do [7:52] you feel how your brain completely [7:54] changes how it engages with that those [7:56] things they are boring things otherwise [7:59] and immediately they change they change [8:01] their nature just because we change the [8:04] shape we molded the shape into something [8:07] that is more comfortable for your brain [8:09] and all of a sudden you could engage it [8:12] changes the way you engage with the same [8:14] problem so that's actually an [8:15] interesting thing because here these are [8:17] not these are not pictures these are [8:20] actually these are actually live [8:23] inspectors there and when they when we [8:25] look at them they look like this right [8:28] this is a really living system and [8:31] you're looking at an actual object in in [8:33] that living system so what you see here [8:37] on the left you have a fraction and then [8:38] we have the color and then there we have [8:40] a folder there we have a picture then we [8:43] have some sort of an algorithm showing [8:45] us the neighborhood [8:47] finding the next neighborhood circle and [8:50] then here we have a data structure of a [8:51] rope of the internal representation of a [8:54] piece of text [8:56] okay so completely different things [8:58] things should look different so that's [9:02] that's the that's the core and it's a [9:04] core property yes we have a question [9:05] here thank you very much for being so [9:07] skeptical I'm not skeptical at all it's [9:12] awesome I was just wondering about the [9:14] this string is that some sort of why is [9:19] that represented as a tree like that [9:21] that's that's a rope data structure okay [9:23] yeah so a rope data structure is one way [9:26] to represent text in a text editor and [9:28] in fact you can look at it like this [9:30] this is a string representation of it [9:32] and this is a textual represent this is [9:33] how the text actually looks like when [9:35] you render it and this is the data [9:37] structure behind that text when you look [9:38] at it very cool things different [9:40] perspectives on the same thing so so [9:43] let's do something with this right so [9:45] now here what I have here is something [9:46] we call a playground so I'll just show [9:51] you a kind of an exploratory thing so [9:53] let's say that I need to go and look [9:56] into my file system so I'm just gonna [9:59] start from my local folder so I'm [10:02] inspecting a folder so now what do I see [10:04] here instead of seeing this which is [10:06] again this is accurate it's a completely [10:09] an accurate description of what is [10:11] inside that object but this is useful so [10:16] so because I have this distinction right [10:19] there's the inspector what I showed you [10:21] here is if I show you an inspector that [10:23] have first of all different views every [10:24] object every individual object can be [10:27] perceived from different views depending [10:28] on the context from which you want to [10:30] look at it so that's one the second one [10:33] is and I'm showing you connected objects [10:35] so here is acute it something and I'm [10:38] showing you the resulting object to the [10:39] right the other thing there the third [10:41] operator here is that when I select [10:44] something over here and I dive into that [10:47] it's basically the same thing so here [10:50] navigations are clicking and executing [10:53] code they are the same they are [10:54] equivalent [10:55] right which basically means that there [10:58] is no necessarily a distinction when [11:00] when the user interface stops I can [11:01] continue programming in fact we look at [11:04] the IDE as [11:05] language to an IDE is not a set of [11:08] features but as a language a language [11:11] made of visual and interactive operators [11:13] that basically can extend the host [11:15] language so let's see what what else can [11:17] you do here so here I have it I have a [11:19] text file so obviously I can see a [11:23] preview of those contents and here for [11:26] example I have a Jason so I can look at [11:29] this Jason and just looking at the [11:31] contents of the file but because it's [11:32] Jason I can look at it like this and now [11:34] this is an actual editor here so I can [11:36] go and change it now remember I'm in an [11:38] inspector inspector was supposed to be [11:41] the smallest or most basic tool that you [11:43] have at your disposal [11:45] so now you see I already see here this [11:49] is a Jason and there's an array over [11:50] here I'm made of some elements and I [11:52] just don't know how many of those there [11:54] are so what could I possibly do I could [11:56] potentially go and scroll here right I [11:59] could do that but this would imply now [12:02] that I'm gonna read my way to finding [12:04] out this answer and that's a highly [12:06] unsophisticated is it a highly manual [12:09] way and we should go we should go away [12:11] from doing that so instead because it is [12:14] Jason Jason is not a text right it's [12:16] super highly structured data so why not [12:19] you know treat it like that so here for [12:22] example I open another playground it [12:24] just works within that context so for [12:26] those that are maybe not familiar with [12:27] this motor system it's like a ripple [12:29] that you apply that it's you know that [12:32] where self is these object that you have [12:34] there now because we already have a [12:37] jsonparser I can just type here I want [12:42] this parser and I say I want to apply [12:45] this parser on the string and now self [12:47] is the file and if I say contents it [12:51] will give me that those contents so now [12:53] I'm parsing that and I get an object so [12:55] now I know they're exactly nine items in [12:57] my array all right then I continue I can [13:00] continue announce navigating like I I've [13:03] done right so much even if my user [13:04] interface maybe was not exactly complete [13:06] I could still catch those things with a [13:09] little bit of a code and then I continue [13:11] navigating there is no there is just to [13:13] continue there's no boundary between you [13:16] know the perspective [13:16] even if the user and then of a developer [13:19] let's that's all the core of of a small [13:22] talk system but we're taking it much [13:24] farther because we have been now [13:26] extended with the language a visual [13:28] language for the IDE now of course [13:31] because we know that this is a typical [13:33] activity it is this Jason from string [13:36] applying it to contents we actually have [13:38] here a little icon right so I can [13:40] actually part click on that one it [13:42] already has that same ability right so I [13:46] learn as I learn what I want from my [13:49] environment the environment grows too so [13:53] this is one one thing too that we could [13:56] do but here's another one it seems like [13:57] here I have a couple of folders and I [14:00] just want to have a quick overview and [14:02] see what you know how deep those folders [14:04] are I don't know so one way to do that [14:07] would be I could just build a map here [14:08] so I could just say let me just I'll [14:12] just open an object on which I could [14:15] just draw something at the beginning I [14:17] don't draw anything so I just want to [14:19] look at the data structure or the folder [14:22] structure for example so I'm just saying [14:24] here I want the nodes for something from [14:28] this folder over here and I want to show [14:31] in that folder all folders so now in [14:36] execute that it's not all folders it's [14:39] all directories now when I execute that [14:42] I get this thing so there are not that [14:44] many actually but let's see how they are [14:46] organized and so I want to create some [14:49] edges now and I'll just connect each of [14:52] these ones from its parent so once I do [14:55] that I start to have some little lines [14:57] there so maybe I will arrange them [15:01] slightly differently now so now I have a [15:04] tree and then I can continue but what's [15:06] interesting about this is that this is [15:07] not a picture right so if I now click on [15:10] one of those I actually go to where I am [15:12] so the tool can evolve with me it is not [15:16] a dead end right so questions so far so [15:24] here's an XML right I see that I have an [15:27] XML over here if I go into it again [15:30] I have you know it's a small catalog of [15:33] books with authors and titles and let's [15:36] say that I'm quickly interested in just [15:38] finding out what are the author's did I [15:39] have in there so again what I do is I [15:42] look at the XML but that's not a piece [15:44] of text it's highly data structure [15:46] although you might not necessarily like [15:47] it it's still highly structured quickly [15:50] quick question how many don't love it [15:51] for now okay good so yeah but we can [15:58] still parse it right so I don't have to [16:01] like it but it's a data structure and I [16:03] want to treat it as if it's a data [16:04] structure so now I'm gonna go and I see [16:07] a tree in there I don't see a piece of [16:08] text so I can still navigate there but [16:10] it's still it's still clumsy so what I [16:12] would like to do is I would just like to [16:14] go and pick only the author elements [16:17] from this tree so what do I do if I have [16:20] an XML and I just want to find some tags [16:21] out of it but what I do [16:23] sorry exponent right so here obviously [16:27] because if we have an element [16:28] I could just say here self XPath and [16:33] maybe say slash author when I execute [16:37] that one I get 12 elements but that's [16:40] you know that's interesting I could do [16:43] these and I could maybe but the thing is [16:44] I can't make this one on a I cannot make [16:47] this one on the button I need to map it [16:49] because I need an input I need a string [16:51] right it's not just a unary execution I [16:54] need to pass in the parameter so in fact [16:56] what I would like to do is I would like [16:58] to extend these ones so maybe here I [17:01] should get a new place where I can put [17:03] that thing so what I will do now in [17:06] order to do exactly that I will now [17:08] switch to the meta tab so the medaka [17:11] gives me the source code it's a browser [17:13] for the object that I am looking at and [17:17] then if I go somewhere and let's say [17:19] that I'm looking for XPath something and [17:21] I think it's probably in node XPath [17:27] should be right right so somewhere here [17:32] there is this method which is called GT [17:35] expat 4 so this is actually I already [17:37] implemented it right so notice how I [17:39] have here this self ex bath whatever it [17:41] says it has a [17:42] and over here with a certain I can and I [17:45] want to apply this button on a text [17:47] editor so now what I want to do is I [17:49] want to say I want to now just and [17:51] annotate the object with this idea that [17:55] you now can present to me than you idiot [17:58] so now if I execute that one [18:00] the magic tab appeared over here right [18:04] it didn't exist and now it exists and [18:05] now it has it's an editor so I can now [18:08] write here slash author and when I run [18:12] this one I get exactly that so what just [18:14] happened here while I was working with [18:17] the tool I notice that I want to extend [18:20] the tool and I take a little few minutes [18:22] and then I extend that tool and I [18:25] continue because then the way we look [18:28] the way objects and everything around [18:31] our software system the way those look [18:34] they determined the way we're going to [18:38] think about them and that's the premise [18:41] of multiple development so now if you [18:43] take a step back here you know what kind [18:45] of a tool is this right is it the file [18:48] browser is it a visualization tool is it [18:52] an editor or is it a query tool right [18:56] it's it's all together there is a [18:58] question there but this idea what I [19:00] wanted to show here is that there are no [19:03] tools silos tools file those are just in [19:05] an arbitrary artifact that were produced [19:08] by you know but essentially by two [19:11] vendors and I think that's a wrong way [19:12] to look at this problem yes thanks how [19:16] do I get like sharing the change I just [19:19] made to the rest of my team oh I will [19:21] commit it to get and then next bill will [19:23] just construct me that you and can I [19:26] still see or reject parts of the comment [19:29] sorry this piece of code is to those [19:35] together with the rest of the source [19:36] code and if I have it and I can put it [19:40] together with the rest of my system or I [19:42] can put it in a different package or [19:44] whatever I want I committed to get and [19:46] then whatever I assemble [19:47] assemblé right doesn't make sense does [19:50] it answer the question okay cool [19:52] now the question so far okay so let's go [19:56] to something so far I just showed you [19:58] some technical things so I want to show [20:00] you a couple of case studies because [20:02] we're using these tools already in real [20:04] life situations in fact we've been [20:07] developing those for about four years [20:08] now and we're this is the second [20:11] generation of the glamorous toolkit and [20:12] we are already using multiple [20:13] development since about five years or so [20:16] so there's this extensive experience [20:19] that we have with this and we we went [20:21] through many case studies so this is the [20:23] most recent one poly poly is is a [20:28] company at which we want to change the [20:32] the way the end user an end user takes [20:35] control of its digital shadow so this [20:38] idea is that your data is now this [20:39] person throughout all of these services [20:42] and they you know they basically control [20:46] they control your data and you don't [20:48] really have access to it but it's [20:50] interesting that in in Europe right with [20:52] the GDP our GDP our forces but vendors [20:56] to actually provide you the data so so [21:00] here's actually we have this idea of a [21:02] pod where it basically lives on your [21:05] machine and in this case I'm showing you [21:08] an inspector over that pod and this part [21:10] basically here I have a few accounts so [21:12] it's e to the rib on LinkedIn and fin [21:15] comm that's the company account on [21:17] Twitter here but on Twitter and to our [21:19] group on Facebook so these are different [21:21] accounts and what's interesting about [21:23] them is that the source code that comes [21:26] so the data that you download you [21:28] actually have to go and request your [21:30] data you download the data and at some [21:32] point it basically looks like this right [21:34] so if I look at the Twitter and I could [21:36] see I see something like that and that's [21:37] I'm familiar with because it looks like [21:39] a Twitter feed but at the same time the [21:41] raw data the data that you actually [21:43] download looks like this [21:45] so maybe here's the contact information [21:49] or the different tweets so they actually [21:55] look in this way right so this is [21:58] actually a Jason wrapped in a Java [22:01] Script I don't know exactly why but [22:03] that's what you get right so again this [22:05] comply is compliant to the law but it is [22:08] not understandable for a human brain or [22:10] for a regular human brain so because it [22:14] is not understandable for us either [22:16] we translate it alright so again it's [22:18] the same thing but now you look at it [22:20] differently and so this ability to [22:23] introspect and go quickly and then [22:26] change the perspective is super [22:28] important is even especially in these [22:30] kinds of cases and development is filled [22:32] with these types of cases right but you [22:34] have to jump the metal level very [22:36] quickly and what's interesting about [22:38] this is that again this is a detailed [22:40] representation of the data and we need [22:43] this representation but at the same time [22:45] this is a user perspective on the data [22:47] something a normal user would understand [22:49] without any kind of knowledge about the [22:52] any technical details so what's [22:54] interesting is because why do we have to [22:56] have this this distance between you know [23:00] a developer who's also happens to be a [23:02] human and other humans that are not [23:05] necessarily developers why can we not [23:06] bring those together and what is not [23:09] this would this not address the problem [23:10] of communication because communication [23:14] problems will come or are generated [23:19] because of the differences in [23:20] perspectives but if we make those [23:22] perspectives apparent the conversation [23:24] completely changes so this is one of [23:28] those cases in which we can use this and [23:33] so where the exploration part is really [23:35] really critical and what's interesting [23:37] about this flow is that actually we're [23:39] spending the largest majority of the [23:41] time the development time in the [23:44] inspector and not in the code browser so [23:48] we will literally develop for the most [23:51] of our time not even in the debugger and [23:53] not in the static code browser but in [23:56] the inspector where the presence of self [23:58] when you always have a self so so that's [24:03] one but I was talking about integration [24:06] at the beginning and I said that [24:07] integration is not necessarily something [24:09] that is that should only include [24:11] developers so [24:14] here's a here's a different perspective [24:15] like we we thought how do we integrate [24:17] norm developers so long technical people [24:20] not just you know maybe users and so but [24:22] on technical people people that [24:23] understand business so one of the you [24:27] know things that are the mediums that [24:30] get exchanged or that basically bridge [24:33] the gap between technical non-technical [24:34] people are documents so here we have a [24:37] different kind of a document engine so I [24:39] want to explain to you how we implement [24:41] it some prices so you saw there's a [24:42] markup language here a markdown kind of [24:45] thing markup language it's not marked [24:47] down and this editor basically makes the [24:51] markup disappears as I as I work with it [24:53] so let's say that I want to take an [24:57] example and I want again I want to just [24:59] describe who this is a financial detail [25:00] about how do we apply discounts on to [25:04] prices so what kind of design did we put [25:06] on that so what I will do here I'll just [25:08] open a piece of code and I will say here [25:12] I want to have a hundred euro as price [25:15] and as I type notice how these buttons [25:17] appear right I didn't there was no edit [25:19] mode and when I run it I get an [25:21] inspector of that one so I have here a [25:23] concrete price so again this already [25:26] exists this whole code runs this is a [25:28] real IDE running there is a real system [25:31] behind it this is another one so so here [25:35] let's say I'm one of these counties one [25:37] by ten euros and if I execute that one [25:40] I'll get a price is counted by money so [25:42] this is basically like a decorator [25:43] pattern how many of you are familiar [25:45] with the decorator pattern okay so yeah [25:48] and so basically this is another another [25:51] another object that wraps the original [25:55] one and applies the discount right so [25:56] like a functional decomposition there so [25:59] let's apply another discount here so if [26:02] I say discounted by 10% [26:04] I get 81 euros exactly what I expected [26:11] so now let's imagine that I want to [26:13] communicate this because we think that [26:15] you know software like we saw in the [26:17] keynote from yesterday [26:18] software like the only truth the main [26:20] truth is in the code but the code shows [26:23] you fact it doesn't it doesn't tell you [26:26] seasons it doesn't tell you why it is [26:28] like that and why it is like that why [26:31] something where anything is the way we [26:34] share it as a you know through our [26:35] culture is through narratives you want [26:38] to tell stories about the kinds about [26:41] the things that are less easy to [26:43] understand so that's what we think the [26:46] idea should be should be a platform for [26:48] storytelling - so here I want to tell [26:51] you a story but now it's a little bit [26:52] difficult because no I want you to tell [26:54] the story of how this is actually [26:55] created so now of course I can go here [26:58] say discount percentage and it's applied [27:00] to 90 euros which is the discounted by [27:03] money which is 10 euro applied to the [27:06] hundred euro which is over here right so [27:08] I could go and navigate from that thing [27:10] which was just top top down I go I go up [27:13] left to right but now I lost in the [27:16] context right so it's a little to [27:19] complicate it so now let's compare this [27:21] one with this view over here alright so [27:25] this view now basically tells me it [27:28] gives me that same object right but now [27:31] I present it differently so I have an [27:32] object over here which is 81 euro is 10% [27:35] off of 90 euros which is 100 euros - 10 [27:38] years ok now again this view only exists [27:43] for this object this is handcrafted for [27:45] this specific object but the interesting [27:47] thing is that the the drawing here was [27:50] drawn by non-technical people on the [27:52] whiteboard and once they drew it on the [27:55] whiteboard it belongs not on the [27:57] whiteboard once a human deems a [27:59] representation of a fact as meaningful [28:01] it's the responsibility of the system to [28:04] carry it forward ok so yeah we can go on [28:09] like this but so another another thing [28:14] here actually is that I don't want to [28:16] write any code into my into my [28:19] documentation because then I have to [28:21] deal with this idea of how do I [28:22] synchronize the code between the real [28:23] code and documentation and so there's a [28:25] whole set of problems but now actually [28:27] wrote this code so that was an example [28:30] that you saw there and now we are also [28:31] using these examples and so because I [28:35] it's like these are like tests but [28:37] they'd return an object [28:39] so here what I want to say is I want to [28:42] just sum on that example and I wanted to [28:43] come over here and when I type and [28:46] notice how there's no edit mode as I [28:48] type here the the the the code is [28:52] someone and comes there and so now I can [28:54] execute that code and I can get it there [28:56] right so I transform my live document [28:59] becomes live as I as I try to throw it [29:02] so maybe I want to say that I don't want [29:03] code at all or and maybe I just want to [29:06] say that I just want to have a preview [29:10] just to show me one of the tabs so I [29:13] just want to show the overview tab and [29:16] as I move away I'm left with the live [29:18] document right it's just a document that [29:21] has no technical detail I can just ship [29:23] to non-technical people and what is [29:25] interesting about this is the cost of [29:26] this document on top of after that if [29:29] the normal development is very very [29:31] small right so so here's an actually you [29:36] know the this one would look like for [29:38] the actual domain so this is these are [29:40] the prices this is an actual system that [29:42] we implemented these are prices that I [29:45] showed you and I'll just show you [29:46] briefly the system also has a workflow [29:49] system that you have in there so here [29:51] for example we have one of these it's [29:55] you know it's a cozy corner over here [29:57] with a kitchen and a guest room and some [30:01] some actors and basically these we model [30:03] them as being actors and so then we want [30:05] to see how what happens when somebody [30:07] places in order so in this case a user [30:10] Ellis gets placed an order over here and [30:13] then he propagated all the way to the [30:15] cook and so I mean I'm still in a in a [30:17] document but here there is a to-do item [30:19] and if I click on that to-do item what [30:22] happens is that the message propagates [30:25] further right so I can learn [30:27] it's an again it's a live documentation [30:29] is a real documentation of a real [30:30] running system but done in a with the [30:35] with the live documentation and the [30:36] interesting thing is that the same idea [30:38] of mouldability can be applied to other [30:39] things such as search so here for [30:41] example we if I now first if I look for [30:43] a class which is object I can see it [30:46] here I can or maybe I look for other [30:48] things as I can see multiple of those so [30:51] that's an interesting thing [30:52] let's say that I'm interested to search [30:54] for du which is a method that for for [30:58] traversing so maybe I just want to look [31:02] for the implementers of that so I can [31:04] see how many there are but maybe I don't [31:07] want to look for doing general I want to [31:10] look inside the collection because I [31:11] know that something is there so now if I [31:13] dive if I if I dive into the collection [31:16] now the scope of the search changed and [31:21] so now when I look for do it will only [31:23] give me the the it will only give me the [31:25] methods it will only give me the methods [31:30] from the collection class right so the [31:34] idea here is that not only does an [31:36] object know how to present itself in [31:37] many ways it also knows how to search [31:39] it's hard to get search so if I apply [31:41] this one to a domain so here I get my [31:43] pot this thing that we implementing for [31:45] the different accounts right so if I [31:47] look for the toolkit I can see the [31:51] different kinds of post this comes from [31:52] gear bar and this comes from a different [31:54] account it comes from Twitter so what's [31:56] interesting here is a now I am searching [31:58] through multiple of those all right and [32:00] again in the same interface but I can [32:02] equally I can equally maybe just go back [32:06] and I just say I will just go inside [32:08] this one and I will if I now search for [32:10] Jie toolkit I don't only get the the [32:14] searches from that account right so the [32:16] search is also scoped and it's very [32:18] simple it's what is interesting here is [32:20] that these are just some examples right [32:22] they didn't handpick I mean I [32:23] hand-picked those but out of many so the [32:26] idea is that if I take a string for [32:30] example and I inspect that one and I see [32:32] a presentation over here this [32:34] presentation and I'll click on to see [32:36] the implementation of that view right [32:38] this is the method that I created before [32:40] to to implement this view over here so [32:45] this method isn't is annotated with GT [32:48] view right so let's quickly find out how [32:50] many of those do we have so if I say GT [32:52] view over here and I'm looking for the [32:54] pragmas which is the name of the [32:56] annotations I can search for that and as [32:59] I search I should get a browser in which [33:01] I can go and navigate so this is an [33:03] actual editor in there [33:04] but let's quickly find out how many [33:05] there are and so they are 725 right now [33:08] right [33:09] so don't quickly find out how many you [33:11] know how many lines of code they all [33:13] have and I have here eight thousand [33:15] seventy eight thousand seven hundred so [33:18] if I do an average now so I get this GT [33:22] view and the GT proud mass and the size [33:25] here what I get is twelve twelve lines [33:29] of code of which two is one is a [33:30] signature and the other one is an [33:31] annotation so ten lines of real code [33:34] that's the cost of a little plugin so I [33:37] have 700 different plugins running at [33:39] the same time in this IDE in the india [33:42] in the daemon I'm giving you so the idea [33:46] here is that every time we talk about [33:47] tools I think we have to talk about [33:48] tools and every time we talk about tools [33:50] we also have to understand what Marshall [33:52] McLuhan and and his students warned us [33:58] from the last previous century and that [33:59] idea that was summarized by John Culkin [34:02] that we shape our tools and thereafter [34:04] our tools shape us right and what [34:08] follows there is that we have to be very [34:10] careful with the characteristics of the [34:12] tools that we expose ourselves to [34:14] because they will determine the way [34:16] we're going to think tools are essential [34:19] in software engineering and they should [34:21] be multiple thank you very much [34:26] [Applause] [34:32] we have a few minutes for more questions [34:35] if you have money everyone here I was [34:41] wondering impressive technology and [34:45] interaction [34:46] I was wondering how if one could isolate [34:52] this interaction and all it comes that [34:55] you said from the underlying language [34:57] yeah I think it's a complicated problem [35:00] but it would be nice if I could write [35:03] multiple languages in within getting the [35:05] same kind of feeling right yeah so [35:08] glamorous toolkit is actually a platform [35:10] I'd be very happy to show you that but [35:12] there's there's much more than meets the [35:14] eye there's actually already a software [35:17] analysis that form in there that deals [35:18] with us already many different languages [35:20] there is also extensive parsing [35:23] abilities and we will definitely target [35:25] other languages yes so this looks good [35:36] for visualizing different kinds of data [35:38] but often when I'm reading code I'm not [35:40] let's say you're trying to figure out [35:41] what's the data I'm working with but I'm [35:43] trying to understand how is the [35:44] algorithm work and what's the process [35:46] I'm going through this glamorous toolkit [35:48] help with that portion of trying to [35:49] understand the oh yeah so the way we [35:51] work with it and again grammar silk it [35:53] is the tool but what's interesting is [35:55] moldable development which is every time [35:57] you replace manual labor with some [35:59] automation the real benefits come from [36:02] when you when you replace the way you're [36:04] fake and so the way we work the way we [36:07] reason and build these kinds of views [36:08] you saw there are several twinning for [36:10] something views right so those 720 [36:13] something views in if you download the [36:15] glamorous toolkit you have about 400 [36:16] something which means that about 250 of [36:19] those are system specific so the [36:23] interesting thing here is that when we [36:25] work and we have a problem we don't just [36:27] solve the problem we don't just write a [36:29] test and solve the problem we build the [36:31] tools write the tests and solve the [36:32] problem and so now where is the problem [36:35] so if I have an object that is now [36:37] telling me or encapsulating an algorithm [36:40] and [36:40] becomes very interesting because there [36:41] is a there is a there's a very [36:44] interesting dialogue between the tool [36:46] because I sometimes want to explain [36:47] something but when it's not first class [36:49] it's very difficult to explain so then I [36:52] very often find myself having to go into [36:54] my algorithm make it first class often [36:56] maybe approach it through an account of [36:59] functional decomposition even if I'm in [37:01] an object-oriented language I work with [37:04] I work with we work with a lot with with [37:06] first class objects and then you [37:08] represent a step in that algorithm like [37:11] that or so for example I show you this [37:13] workflow right that was a one message so [37:16] we refined a message just because we [37:18] wanted to show you how the message [37:20] propagates through the different actors [37:22] and that was an algorithm so this is how [37:24] it works thank you very much again [37:35] you [37:45] you