DEV Community: Jorge Luis Perez

Modular Java Builds with Gradle: From Setup to Strategy

Jorge Luis Perez — Sun, 06 Apr 2025 16:24:13 +0000

In this hands-on guide we'll see how we can configure composite builds in a simple way using the Gradle command line utils as much as possible — plus a bit of how I used them to break up a monolith on the way to microservices.

Why Use Composite Builds?

Composite builds are a powerful Gradle feature that address the challenges of modular development, particularly in projects that need to evolve independently but still integrate reliably. They offer several practical advantages:

Live dependency substitution: You can replace the typical change–publish–install workflow with a direct project dependency. This means that any changes you make to a library are immediately visible to the consuming application—no need to publish intermediate versions.
Modular development within monorepos: Composite builds let you split a monorepo into multiple independent builds. You can work with each module in isolation for faster feedback, and use the full composite to verify everything still works together.
Temporary or ad hoc integration: You can integrate separately developed projects without merging their structures. This is especially useful for testing changes across repositories or coordinating temporary collaborations before publishing a new version.

Scaffolding the Projects

Let's create the root directory that will contain the projects:

$ mkdir composite

In this example, we'll create and application and a library projects.

$ cd composite
$ mkdir application
$ mkdir library

A tree command run should return:

.
├── application
└── library

2 directories, 0 files

Use the gradle init command to create the structure for the projects.

$ cd application
$ gradle init \
  --type java-application \
  --dsl kotlin \
  --test-framework junit-jupiter \
  --package com.example.app \
  --project-name application \
  --no-split-project \
  --java-version 21 \
  --incubating

Next the library project:

$ cd ../library
$ gradle init \
  --type java-library \
  --dsl kotlin \
  --test-framework junit-jupiter \
  --package com.example.lib \
  --project-name library \
  --no-split-project \
  --java-version 21 \
  --incubating

At this point, a tree -d -L 4 command run from the root directory should return:

.
├── application
│   ├── app
│   │   └── src
│   │       ├── main
│   │       └── test
│   └── gradle
│       └── wrapper
└── library
    ├── gradle
    │   └── wrapper
    └── lib
        └── src
            ├── main
            └── test

Now, we've the basic structure of two unconnected projects. Let's make a composite build with them.

Composite Build Configuration

From the root directory, we'll create an empty Gradle settings file so we can generate the Gradle wrapper.

$ touch settings.gradle.kts
$ gradle wrapper

After that, in settings.gradle.kts at the root directory, we must inform to Gradle which builds are included in the composite:

// ../composite/settings.gradle.kts
rootProject.name = "composite"

includeBuild("application")
includeBuild("library")

To test our configuration, run the following from the root project directory:

$ ./gradlew projects

That should return the following:

> Task :projects

Projects:

------------------------------------------------------------
Root project 'composite'
------------------------------------------------------------

Root project 'composite'
No sub-projects

Included builds:

+--- Included build ':application'
\--- Included build ':library'

To see a list of the tasks of a project, run gradlew <project-path>:tasks
For example, try running gradlew :tasks

BUILD SUCCESSFUL in 789ms
1 actionable task: 1 executed

Now the projects are included in the same composite, but still unrelated without any real dependency between them.

Connecting the Builds

Let's use the library in the application project. In order to do that we need to edit the build.gradle.kts files in the lib and in the app modules.

// ../composite/library/lib/build.gradle.kts
group = "com.example"
version = "0.0.1

Now, in the application module, we can add the library as a dependency:

// ../composite/application/app/build.gradle.kts

dependencies {
    //...
    implementation("com.example:lib:0.0.1")
}

One interesting thing to notice here is that we declared the library as if it were a binary dependency, using its group, name, and version. From the application’s perspective, it looks just like any third-party dependency — but with one huge advantage: thanks to composite builds, Gradle automatically substitutes it with the local project source. Any change made in the library is immediately seen by the application, without needing to publish or install anything. That’s the magic of composite builds.

Let's make some use of the library from the app code:

package com.example.app;

import com.example.lib.Library; // Import the library

public class App {
    public String getGreeting() {
        return Library.getGreeting(); // Get the greeating from library
    }

    public static void main(String[] args) {
        System.out.println(new App().getGreeting());
    }
}

In Library, just add the necessary method:

package com.example.lib;

public class Library {
    public static String getGreeting() {
        return "Hello from Libray!";
    }
    //...
}

Let's run app:

$ ./gradlew :application:app:run

Here's the output:

> Task :application:app:run
Hello from Libray!

BUILD SUCCESSFUL in 1s
4 actionable tasks: 1 executed, 3 up-to-date

If we then change the library greeting message and run the app again, the app will notice the change immediately.

public class Library {
    public static String getGreeting() {
        return "Hello there!";
    }
    //...
}

Voila!

> Task :application:app:run
Hello there!

BUILD SUCCESSFUL in 10s
4 actionable tasks: 3 executed, 1 up-to-date

Other Considerations

Internal Wrappers

We used the gradle init command to generate the project structure, which also created a Gradle wrapper (./gradlew). You should keep an internal Gradle wrapper in a project only if that project is meant to be developed or used independently — for example, if it’s published separately, run in its own CI pipeline, or needs to pin a different Gradle version. In typical composite builds or multi-project setups where everything is built together from the root, you don’t need internal wrappers — they just add clutter. Keep a single wrapper at the root unless there's a strong reason not to.

Internal Versions Catalogs

The same consideration applies to version catalogs. You should define a libs.versions.toml file in an included build or individual project only if that project is intended to be consumed in isolation. If you're working in a composite build where modules are developed together, it's best to define a single shared catalog in the root build. This avoids duplication, reduces maintenance overhead, and keeps dependency versions consistent across builds. As with wrappers, use separate version catalogs only when you genuinely need independence.

By default, the libs.versions.toml file is placed in the gradle/ directory alongside the wrapper JAR in every generated module. If you want to use a single shared version catalog, you'll need to add an extra piece of configuration to the settings.gradle.kts file of each included build: the dependencyResolutionManagement block.

rootProject.name = "library"

include("lib")

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}

Now the libs version catalog refers to the libs.vesions.toml file in the root directory and you can safety remove the ones inside the modules.

Root Build Script

One last thing you should consider is adding a build script in the composite's root directory to define some global tasks. Here's an example:

defaultTasks("run")

tasks.register("run") {
    dependsOn(gradle.includedBuild("application").task(":app:run"))
}

tasks.register("testAll") {
    dependsOn(gradle.includedBuild("application").task(":app:test"))
    dependsOn(gradle.includedBuild("library").task(":lib:test"))
}

This setup allows you to run ./gradlew testAll from the root directory to execute all tests across the composite build.

If you decide to use a single wrapper, a single version catalog and a root build script you'll end up with the following directory structure.

.
├── application
│   ├── app
│   │   ├── build.gradle.kts
│   │   └── src
│   │       ├── main
│   │       │   ├── java
│   │       │   │   └── org
│   │       │   │       └── example
│   │       │   │           └── App.java
│   │       │   └── resources
│   │       └── test
│   │           ├── java
│   │           │   └── org
│   │           │       └── example
│   │           │           └── AppTest.java
│   │           └── resources
│   └── settings.gradle.kts
├── build.gradle.kts
├── gradle
│   ├── libs.versions.toml
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── library
│   ├── lib
│   │   ├── build.gradle.kts
│   │   └── src
│   │       ├── main
│   │       │   ├── java
│   │       │   │   └── org
│   │       │   │       └── example
│   │       │   │           └── Library.java
│   │       │   └── resources
│   │       └── test
│   │           ├── java
│   │           │   └── org
│   │           │       └── example
│   │           │           └── LibraryTest.java
│   │           └── resources
│   └── settings.gradle.kts
└── settings.gradle.kts

Composites in a Monolith-to-Microservices Scenario

A few years ago, I was working on a system that had started to show serious scalability issues — both in terms of performance and design flexibility. It followed a classic three-layer architecture:

A REST API layer that handled requests from the UI and external systems
A middle layer containing the business logic
An integration layer responsible for communicating with various third-party providers

The integration layer, in particular, had become a bottleneck. It was monolithic in structure and hard to evolve. Performance was another challenge — each provider had very different response characteristics, which made it difficult to scale or even size that layer appropriately.

We knew we needed to evolve toward a more modular architecture, but a full rewrite wasn’t realistic. Instead, we chose a path of incremental decomposition. The goal was to isolate provider-specific logic that could be developed and tested independently, without breaking the existing deployment model.

To enable this, we adopted Gradle composite builds. Rather than splitting the integration layer into separate microservices immediately — which would have required significant coordination, deployment, and CI complexity — we began extracting provider connectors into standalone Gradle builds. These builds could be version-controlled separately, tested in isolation, and evolved at their own pace.

Using includeBuild(...), we wired them back into the main system as source dependencies. This gave us the benefits of modularity without forcing early service boundaries or dependency publication. Because Gradle treated them as if they were published artifacts, nothing had to change in the rest of the system.

To keep the business logic layer insulated from these changes, we introduced a small internal SDK — a module that exposed a stable interface to the provider connectors. It encapsulated provider selection logic and served as a boundary between the modularized integration code and the core application. In some cases, the SDK imported the connector directly using includeBuild(...); in others, it routed requests over HTTP to connectors that had been promoted to microservices. This dual-mode setup allowed us to evolve the architecture incrementally behind a unified interface, without impacting the rest of the system. It also helped maintain a consistent developer experience throughout the transition.

This approach gave us several advantages:

We could work on or refactor connectors without having to touch unrelated parts of the system, because each connector lived in its own isolated build and interacted with the rest of the application only through a stable SDK interface.
Teams could build and test connectors independently, which sped up local development and reduced unnecessary work in CI, because the connectors were split into separate builds with their own lifecycle and caching behavior.
Over time, we could graduate some of these connectors into fully independent microservices — often without changing their internal APIs.

This setup wasn’t without tradeoffs. It introduced more build logic and required engineers to become comfortable working across multiple Gradle builds. But the gains in modularity, velocity, and long-term flexibility far outweighed the initial complexity.

In practice, composite builds gave us an architectural bridge between monolith and microservices. They enabled controlled, observable evolution — allowing us to restructure the system without stopping the world.

Wrapping Up

Gradle composite builds offer a clean and flexible way to work with multiple independent projects as if they were part of a single unified system. In this tutorial, we used gradle init to scaffold the project structure, configured the composite with includeBuild, and wired everything together using a shared wrapper, version catalog, and root build script. This setup allows changes in one project to be immediately reflected in others, without the need to publish or install artifacts — enabling faster feedback loops and smoother cross-project collaboration.

Beyond simple modularization, composite builds can also serve as a practical bridge during architectural transitions. As shown in the monolith-to-microservices example, they make it possible to incrementally extract parts of a system and defer deployment decisions without sacrificing testability or development speed. Whether you're modernizing a legacy system or building modular applications from scratch, composite builds give you the structure to scale with confidence — both technically and organizationally.

Licensed under CC BY-SA 4.0.

References:

Introducing Composite Builds

Composite Builds

Rust Key Concepts (I): Ownership System

Jorge Luis Perez — Fri, 07 Feb 2025 20:57:36 +0000

Rust has specific design choices and feature selections that make the language unique. Let’s dive into the key concepts that lead us to a deeper understanding of the language.

Ownership System

Ownership is hands down one of the first big ideas a newcomer to Rust has to wrap their head around. To really grasp Rust's ownership system, some background knowledge about variables, memory regions, and memory management is essential. This foundation will help you develop a solid mental model of what's going on. However, instead of diving into all that theory right away, let's start by building a practical sense of how the ownership system works. Let's set up a problem scenario and see how we can tackle it.

In Rust, when we write something like this:

let message = String::from("Hello Rust!");

We are doing more than simply assigning the “Hello Rust” string to the variable message. We’re binding the string — the value — to a scope.

Which scope? The one where the variable is defined.

{  
   let message = String::from("Hello Rust!");  
}

Statically, the syntax defines the scope as the block enclosed by the opening and closing braces.

t0 {  
t1   let message = String::from("Hello Rust!");  
t2 }  
t3

Dynamically speaking, the execution flow proceeds top-down, from the opening brace to the closing brace, spanning from t0 to t3.

At t0, a new scope is defined.

At t1, a variable message is declared and initialized, allocating memory for the string. The lifetime of the string value is also bound to the scope of the variable message.

When execution reaches t2, the variable message goes out of scope, and the value associated with the variable is dropped from memory, deallocating the memory reserved at t1.

At t3, the program flow continues after the block, but the message variable is no longer accessible because it was dropped when the block exited.

In Rust parlance, we would say that The message variable is the owner of the string ‘Hello Rust!’. Technically, Rust couples the lifetime of a value in memory with the scope of the variable associated with that value.

If you come from a memory-managed language, this behavior might not impress you because it’s exactly what you expect — you don’t even need to think about it. However, the key difference is that this mechanism is determined at compile time. Rust shifts the memory management problem from run time to compile time, so you don’t incur extra run time overhead for automatic memory management.

Another important distinction compared to a typical garbage collection (GC) algorithm is that Rust’s memory management is deterministic — you know exactly when a value will be dropped. In contrast, with a GC, you can’t predict precisely when it will pause your application thread to perform garbage collection.

From the perspective of a C programmer, the benefits are more tangible because, in C, memory management is manual. With Rust, the compiler prevents many common problems associated with manual memory management, such as use-after-free errors, double-free errors, some memory leaks, dangling pointers, and out-of-bounds indexes.

As we can see, the semantics of assigning a value to a variable in Rust are denser than in other programming languages because they implicitly include an ownership declaration.

Rust has clear rules about ownership:

Each value in Rust has an owner.
There can only be one owner at a time.
When the owner goes out of scope, the value will be dropped.

These rules are checked at compile time, which means that if any of them are violated, we’ll get a compilation error, preventing us from generating an executable with memory management deficiencies.

Rust shifts the memory management problem from run time to compile time.

Let’s keep that in mind and explore how the ownership system affects Rust’s programming.

Ownership Moving

Here is a slightly more complex code:

fn print_message(message: String) {  
  println!("{message}");  
}

fn main() {  
   let message = String::from("Hello Rust!");

   print_message(message);  
}

The message variable is assigned in the main function's scope and passed as an argument to another function that prints the message. This code compiles successfully, meaning all ownership rules are upheld.

The program not only compiles but also runs without any issues.

$ cargo run  
   Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s  
    Running `target/debug/rust-kc-p1`  
Hello Rust!

Now, we want to print not only the message but also its size after printing the message itself.

fn print_message(printable_message: String) {  
  println!("{message}");  
}

fn print_message_size(sized_message: String) {  
   println!("{}", message.len());  
}

fn main() {  
   let message = String::from("Hello Rust!");

   print_message(message);

   print_message_size(message);  
}

To achieve this, we added another function to calculate and print the size, calling it after the first message was printed. However, there’s a problem: the compiler complains about our latest addition.

$ cargo run  
  Compiling rust-kc-p1 v0.1.0 (/home/jolisper/src/rust-key-concepts/rust-kc-p1)  
error[E0382]: use of moved value: `message`  
 --> src/main.rs:16:24  
   |  
12 |     let message = String::from("Hello Rust!");  
   |         ------- move occurs because `message` has type `String`, which does not implement the `Copy` trait  
13 |  
14 |     print_message(message);  
   |                   ------- value moved here  
15 |  
16 |     print_message_size(message);  
   |                        ^^^^^^^ value used here after move  
   |

Rust’s compiler error messages are usually helpful and often suggest ways to fix the problem. But to get the most out of them, you need a good grasp of how the ownership system works.

Every time the Rust compiler stops you, it’s because a design decision must be taken. Any design decision comes with its trade-offs. My advice here is not to rush and to solve the problem quickly or blindly follow the suggestions. Instead, invest the time to really understand why the error occurs; it is the best option in the long run.

I will say it again.

Rust shifts the memory management problem from run time to compile time.

That means we have to solve more problems before our program can run. Spending more time on this part of the process is completely natural. Keep that in mind the next time the anxiety of getting your program running starts creeping up your fingertips.

Coming back to the code, the key thing here is that the compiler tells us we’re trying to use a moved value. What does this mean? Let’s revisit Rust’s ownership rules:

Each value in Rust has an owner.
There can only be one owner at a time.
When the owner goes out of scope, the value will be dropped.

Let’s focus on the second rule. This clearly states that there can only be one owner for each value, but this doesn’t mean the owner must remain the same throughout the entire program’s execution. In fact, ownership can change hands during the program’s execution. For instance, when a value is assigned to another variable, added to a vector, or stored on the heap, ownership of the value moves from its original location to the new one. And that’s exactly what happens in this case.

When we first bind the “Hello Rust!” string to the variable message, that variable becomes its owner. However, when we pass the message variable as an argument for the print_message() function, the ownership of the value is transferred to the function’s parameter variable, printable_message. As a result, the original variable, message, loses its ownership of the value because it was moved. After this, the message variable in the main function is no longer valid, and attempting to use it again will result in a compilation error.

It's important to note that the scope of the string “Hello Rust!” changes when ownership is transferred. The new scope is defined by the print_message function. This means that when the print_message function returns, the printable_message parameter goes out of scope, resulting in the string being dropped. In cases like this, it is common to say that a function consumes the value.

The process described in the previous paragraph also applies to the first version of the code, where the print_message() function is the only additional function defined. However, since there is no attempt to reuse the message variable, no ownership rules are violated, and the code compiles successfully.

From here, things get interesting because Rust begins to reveal its full arsenal. There are several ways to resolve the issue, each with its trade-offs. It’s up to us, the programmers, to decide which path is best for our problem.

The ownership system is so prevalent in Rust that talking about it implies touching several other language features and concepts. To keep ownership at the center, in the rest of the article, we'll touch on them briefly, without deep dives, just to explain different aspects of the ownership system. You might feel tempted to take a bigger detour into those topics when that happens, but my humble advice is to take a deep breath, relax, and keep reading to build a practical sense of how the ownership system works before jumping to them. Consider these as glimpses into future articles.

Use of Moved Value

Now that we've set up the problem, we’re ready to dive into the options for solving it. We’re not aiming to cover every possible solution here. Instead, we’ll explore a handful of approaches that let us dig into the nuances of the ownership system and put the basics we covered earlier to the test.

Return Ownership Back

One way to overcome the use of a moved value error is to make sure that the function returns the string passed as an argument and use that return value to call the other function.

fn print_message(printable_message: String) -> String {  
  println!("{printable_message}");  
  printable_message  
}

fn print_message_size(sized_message: String) {  
   println!("{}", sized_message.len());  
}

fn main() {  
   let mut message = String::from("Hello Rust!");

   message = print_message(message);

   print_message_size(message);  
}

Also, since the value is returned, we can avoid the intermediate assign of the message variable and chain the functions calls:

fn main() {  
   let message = String::from("Hello Rust!");

   print_message_size(print_message(message));  
}

While this might not be the first option in practice, it demonstrates how a function can take and return ownership of a value. It’s important to note that this process does not require any additional allocation.

In terms of ownership, we are adding an extra moving step to solve the issue: the returned ownership in the print_message function. Interestingly, the value itself isn’t what matters here. For example, we can return a completely different String value from the function, and the code still compiles:

fn print_message(printable_message: String) -> String {  
   println!("{printable_message}");  
   String::from("Another string value")  
}

fn print_message_size(sized_message: String) {  
   println!("{}", sized_message.len());  
}

fn main() {  
   let mut message = String::from("Hello Rust!");

   message = print_message(message);

   print_message_size(message);  
}

Of course, this breaks the functionality, as we are now printing the size of a new String rather than the original one.

Hello Rust!  
20

This reveals an important point: under Rust’s ownership rules, the specific values assigned to variables are irrelevant. What truly matters is the ownership flow through the variables and function calls.

Ownership and Mutability

Rust does not provide immutable values out of the box but provides immutable variables by default. This variable mutability condition is inherited by the value that the variable refers to, which means that a value behind an immutable variable is immutable, too¹. If we want to declare a variable as mutable, we must do it explicitly using the mut keyword in the variable declaration. This principle that transmit the mutability condition of a variable to the value behind it is called: inherited mutability.

In the example that serves as a problem scenario, we are using an immutable variable that refers to a String value holding the message to print out. But observe the following subtle change.

fn print_message(mut printable_message: String) {
    printable_message.push_str(" From a function");
    println!("{printable_message}");
}

fn main() {
    let message = String::from("Hello Rust!");

    print_message(message);
}

When ownership is moved, the function that takes ownership can decide to change the mutability condition of that value. In this case, although the variable passed as argument is immutable, the function decided to change that condition and made the value mutable.

Hello Rust! From a function.

Here is another version using shadowing.

fn print_message(printable_message: String) {
    println!("{printable_message}");
}

fn main() {
    let scrolling = String::from("A long time ago ");

    // scrolling.push_str("far far away"); // error: cannot mutate immutable variable value

    let mut scrolling = scrolling;

    scrolling.push_str("in a galaxy far, far away...");

    print_message(scrolling);
}

This shows us an important relation between mutability and ownership: when they are moved, owned values can be switched from immutable to mutable.

Cloning

Another way to overcome the issue is to simply avoid moving the value by passing a clone of the original instead.

fn print_message(printable_message: String) {  
   println!("{printable_message}");  
}

fn print_message_size(sized_message: String) {  
   println!("{}", sized_message.len());  
}

fn main() {  
   let message = String::from("Hello Rust!");

   print_message(message.clone());

   print_message_size(message);  
}

In this version, we create a copy of the original string and pass that copy as an argument to the print_message function. No ownership transfer happens in this case, but we are expending the double memory until the end of print_message() because we are allocating a copy of the string.

The need to explicitly call the clone() function for cloning a value is considered an advantage because it’s made explicit that the cloning occurs. To make this call, the type must implement the Clone trait. If we define our custom type, such as a struct, and all its fields implement Clone, the implementation is derivable.

#[derive(Clone)]  
struct Person {  
   name: String,  
   age: u8  
}

In this type of solution, evaluating the cost of the cloning is important. If the value is small, like in this example, the performance cost could be irrelevant, but in other cases where the value is big or if the cloning is inside a loop creating a lot of copies, the cost may represent too much.

Cloning everywhere is considered an anti-pattern in Rust because calling the clone() function introduces performance overhead, as every call creates a new memory allocation. Let’s explore alternative solutions to the problem scenario and return to this later.

Reference Counting

Let’s revisit the second rule of the ownership system:

There can only be one owner at a time.

This rule is concise and clear, but, put differently, what’s truly restricted is shared ownership of a value. At times, this rule might feel overly restrictive and could hinder valid patterns. For example, if we need to share an immutable value, what’s the issue with sharing its ownership?

In Rust, the reference counting smart pointer, Rc<T>, provides shared ownership of type T. Reference counting is a memory management technique where an allocated value keeps a count of how many references (or owners) point to it.

use std::rc::Rc;

fn print_message(printable_message: Rc<String>) {  
   println!("{printable_message}");  
}

fn print_message_size(sized_message: Rc<String>) {  
   println!("{}", sized_message.len());  
}

fn main() {  
   let message = Rc::new(String::from("Hello Rust!"));

   print_message(message.clone());

   print_message_size(message.clone());  
}

When you clone an Rc<T>, another pointer to the same allocation is created, and the reference count is incremented². When an Rc<T> goes out of scope, its drop logic decrements the reference count. If the count reaches zero, the value is deallocated.

This means that Rc does not create a copy of the value T; it merely increments or decrements the reference count. As a result, this approach introduces some overhead because Rc needs to keep track of how many owners the value T has. In situations where we want or need to share the same instance of an object across different parts of a program, the Rc smart pointer comes in handy.

Using References

In the previous solutions:

We return ownership back, using a function that takes and gives ownership back to the caller.
Avoid ownership move by passing a deep copy of the value to the function with clone().
We relaxed the "only one owner" ownership system rule using shared ownership through Rc<T> smart pointer.

Those solutions have one important thing in common: all three are pass-by-value solutions³. Another possibility allows us to use the value in another scope while keeping the original ownership intact. We achieve that by using references.

fn print_message(printable_message: &String) {
    println!("{printable_message}");
}

fn print_message_size(sized_message: String) {
    println!("{}", sized_message.len());
}

fn main() {
    let message = String::from("Hello Rust!");

    print_message(&message);

    print_message_size(message);
}

We can think of references as pointers that allow us to access data without taking ownership of it. The difference with a typical C pointer is that we can't make any pointer arithmetic on them, also they are restricted to specific rules. References add two more rules to the ownership system:

At any given time, you can have either one mutable reference or any number of immutable references.
References must always be valid.

The first rule tells us that references come in two flavors: mutable, and immutable. The first ones are denoted by & and the second ones are denoted by &mut. We can have any number of immutable references to a value or only one mutable reference to the same value at the same time. That's the reason why the immutable references are often called shared references, and the mutable ones are typically referred to as exclusive references. You can share or mutate, but not both.

Allowing access to a value in another scope without transferring ownership opens the door to new problems. The ownership system must ensure that the references point exclusively to non-dropped values. That is what the second rule is all about.

Notice that the print_message() function was changed to receive a reference of the message, but the print_message_size() is still taking ownership of the value. Because the print_message() function doesn't take ownership of the message value, the owner is still the message variable defined in the main function until the second function is called, and that does not break any rule of the ownership system. The code compiles.

Now let's explore what happens if we invert the call function order:

fn main() {
    let message = String::from("Hello Rust!");

    print_message_size(message);

    print_message(&message); // error: borrow of moved value.
}

The compile error changes, telling us that we are trying to take a reference of a value that was moved. A reference is valid when its lifetime is equal to or less than the lifetime of the value that it points to.

fn main() {
    let msg_ref;
    {
        let message = String::from("Hello Rust!");
        msg_ref = &message; // error: `message` does not live long enough
    } 

    print_message(msg_ref);
}

In this example, we define a reference variable in the main function scope and initialize it with a reference to a value bonded to an internal scope smaller than the full main function scope.

When we use that reference after the inner scope has ended, the compiler tells us that the value behind the reference does not live long enough. In other words, the compiler tells us that the reference lifetime is greater than the lifetime of the value that's pointing to. Using a reference that points to a dropped value leads to undefined behavior, so the compiler inhibits that possibility.

In Rust parlance, when a function takes a reference as a parameter, we say that the function borrows the value. Besides the ownership moving semantics, borrowing is the other complementary concept that is prevalent is Rust. The borrow checker is the part of the compiler that enforces the Rust's ownership and borrowing rules at compile time.

A full discussion about borrowing must include an explanation of lifetimes, especially generic ones. That topic demands special attention, but since we need to understand the basics of the ownership system first, we’ll leave it for another article.

Ownership is the path to the lifetimes. Ownership leads to borrowing. Borrowing leads to references. References lead to lifetimes.

Take, Replace (and Swap)

These two options have very specific use cases. In the context of this example, they are more hacks than real solutions, but it is good to know they exist.

fn print_message(printable_message: String) {  
   println!("{printable_message}");  
}

fn print_message_size(sized_message: String) {  
   println!("{}", sized_message.len());  
}

fn main() {  
   let mut message = String::from("Hello Rust!");

   print_message(std::mem::take(&mut message));  

   print_message_size(message);  
}

Here, we use the generic function mem::take<T>(&mut T); this function returns the value behind the mutable reference and replaces its original value with the type's default value. If we run this code, the output is:

Hello Rust!  
0

That’s not the correct result because print_message() received the original value, but the value of the variable message was replaced with the default value, which, in the case of the String type, is an empty string.

Why does this work in terms of ownership? Because mem::take(&mut T) -> T receives a mutable reference of T from which extracts the current value, returns it as an owned value, and, in the middle, replaces the original value with the default value for T.

As a result, from the perspective of the ownership flow, nothing changes; the message variable never loses ownership of a value. It's just that the good old mem::take() swoops in, sneakily swipes the current value from message's pocket, and replaces it with a new one of equal weight. The sleight of hand is so smooth that message remains blissfully unaware of what transpired, and the ownership rules remain perfectly intact.

Technically, mem::take(&mut T) -> T is a special case of mem::replace(&mut T, T) -> T with the default value of T as a second argument; in fact, mem::take() uses mem::replace() internally.

fn main() {  
   let mut message = String::from("Hello Rust!");

   let other_message = String::from("Another string value"); // len = 20

   print_message(std::mem::replace(&mut message, other_message));  

   print_message_size(message);  
}

That’s prints:

Hello Rust!  
20

Just to show the third friend of this group of functions, we’ll see an example of mem::swap(&mut T, &mut T), which does exactly what we expect.

fn main() {  
   let mut message1 = String::from("Hello Rust!");  
   let mut message2 = String::from("Goodbye Rust!");

   std::mem::swap(&mut message1, &mut message2);  

   print_message(message1);

   print_message(message2);  
}

Printing the result:

Goodbye Rust!  
Hello Rust!

Redesign to Avoid Ownership Transfer

Another valid option is to rethink how the code manages ownership of values throughout its structure.

fn print_message(printable_message: String) {  
   println!("{printable_message}");  
   println!("{}", printable_message.len());  
}

fn main() {  
   let message = String::from("Hello Rust!");

   print_message(message);  
}

Reconsidering the function call order while keeping the final result intact is valid. So, rethink the way that the code is handling ownership of the values through our code should serve us as a trigger to build a better solution, it forces us to find other way to get the same result, if we have the intention to simplify things, in general that lead us to better solution.

Inlining

This can be thinking as a special case of the previous option. If we inline the print_message_size() function call, we end up with this:

fn main() {
   let message = String::from("Hello Rust!");

   println!("{printable_message}"); // manual inlined function

   print_message_size(message);  
}

Removing the function call also eliminates the ownership transfer. While this could resolve the ownership issue, it is not always a practical solution, as it may lead to code duplication and future maintenance challenges.

Just to mention, Rust has a function attribute called #[inline]:

#[inline(always)]
fn print_message(printable_message: String) {
    println!("{printable_message}");
}

fn print_message_size(sized_message: String) {
    println!("{}", sized_message.len());
}

fn main() {
    let message = String::from("Hello Rust!");

    print_message(message);

    print_message_size(message);
}

But serves as a compiler hint and not as an actual order that could solve ownership problems. The code is still not compiling.

  --> src/bin/inlining.rs:15:24
   |
11 |     let message = String::from("Hello Rust!");
   |         ------- move occurs because `message` has type `String`, which does not implement the `Copy` trait
12 |
13 |     print_message(message);
   |                   ------- value moved here
14 |
15 |     print_message_size(message);
   |                        ^^^^^^^ value used here after move
   |

Related Concepts

After exploring ways to overcome the 'use of moved value' scenario, it's worth learning about some related concepts to complete the ownership picture.

Avoid cloning

The clone() method creates a deep copy of a value, which in particular does not have anything bad at prior. However, overuse can produce unwanted performance problems and memory bloat, especially if we use it as an easy way to avoid ownership issues.

That configures the typical Rust tension between cloning and the ownership system, which is why many Rust programmers raise flags against using clone(). Even so, we must escape from any dogmatic crusade in software design.

What's really important here is to remember that:

Every time the Rust compiler stops you, it’s because a design decision must be taken.

Cloning comes with a cost, and that cost should be carefully considered in the context of our design. It's worth taking the time to ask ourselves a few questions before simply writing .clone() after naming a value:

Can ownership be taken instead?
Would a reference suffice here?
Could shared ownership through a smart pointer address the problem?

As a rule of thumb, use .clone() only when there is a specific reason for creating a new copy.

Copy Trait

For a moment, let's focus on another simple example:

struct Point {
    x: i32,
    y: i32,
}

fn print_x(p: Point) {
    println!("{}", p.x);
}

fn print_y(p: Point) {
    println!("{}", p.y);
}

fn main() {
    let p1 = Point { x: 10, y: 20 };

    print_x(p1);

    print_y(p1); // error: use of moved value: `p1`
}

This code is similar to the previous example in the sense that we are getting the same error from the compiler. But the kind of the types that our Point struct is based on allows us to use another way of solving the ownership issue.

#[derive(Copy, Clone)]
struct Point {
    x: i32,
    y: i32,
}

Because our struct uses only copy values, we can derive the Copy trait for Point. Copy values in Rust refer to values of types that implement the Copy trait. This trait allows for the duplication of values without transferring ownership. The Copy trait is automatically implemented for simple, fixed-size types, like integers, floating-point, booleans, and character types.

Using the Copy trait for custom types involves design decisions similar to those made with the clone() method use. The key difference lies in their purposes: Copy is a marker trait that signals to the compiler that a type's value can be duplicated by simply copying its bits in memory. In contrast, the Clone trait defines an explicit method for creating a copy of a value. For types implementing Copy, values are automatically duplicated instead of being moved when passed to a function or assigned to another variable. In this sense, the Copy trait represents a controlled exception to Rust's default move semantics in the ownership system.

Interior Mutability

Some smart pointers (Cell, RefCell, RwLock, Mutex) allows the use of the pattern known as interior mutability. Interior mutability allows us to mutate a value through a shared reference. I can almost hear you saying:

Wait! What? We've seen that there are two types of references: mutable and shared. We can't mix them—we can either share or mutate through them, but not both!

My answer is, 'Yes, you are right,' but this pattern is an exception to the ownership rules we've seen before—in more ways than one.

First, it clearly allows something that is otherwise forbidden:

At any given time, you can have either one mutable reference or any number of immutable references.

With this approach, we can have multiple shared (immutable) references while still allowing mutation of the value through any of them. In other words, it violates the principle of inherited mutability

Second, inherited mutability is enforced at compile time by (of course) the compiler. However, interior mutability relies on run time checks for safety. This means that the this family of containers enforces the necessary borrowing rules dynamically, allowing mutation through shared references while maintaining safety within their defined constraints. However, unlike inherited mutability, which ensures safety at compile time, this approach introduces a run time cost, as the rules are enforced programmatically during execution.

Third, because the rules of interior mutability are checked at run time, violations result in run time errors. This means that, for the interior mutability portion of a program, the occurrence of memory management issues depends on the program’s logic and the execution paths determined by run time conditions. These conditions are outside the compiler's scope, preventing it from catching such issues. This breaks Rust’s promise of catching these types of problems at compile time.

Why does interior mutability even exist if it comes with all those drawbacks? The Rust compiler is quite conservative about what constitutes a valid program. In terms of memory safety, it prefers to be strict, even at the cost of having false positive classifications of unsafe programs. Using group theory terminology, we could say that the set of memory-safe programs is a superset of the programs allowed by the Rust compiler. This leaves a whole subset of valid programs that cannot be represented without the interior mutability pattern.

use std::cell::Cell;

struct Counter {
    count: Cell<u32>, // instead of: "count: u32"
}

impl Counter {
    fn new() -> Counter {
        Counter { count: Cell::new(0) }
    }

    fn increment(&self) {
        // self.count += 1; // cannot assign to `self.count`, which is behind a `&` reference
        self.count.set(self.count.get() + 1);
    }

    fn get(&self) -> u32 {
        self.count.get()
    }
}

fn main() {
    let counter = Counter::new();
    println!("Initial count: {}", counter.get());
    counter.increment();
    println!("Incremented count: {}", counter.get());
}

In the example above the interior mutability pattern allow us to expose an immutable interface of the counter but and the same time encapsulating the mutation of the counter in the increment method.

Summary

Based on simple examples we learnt the rules of the ownership system, and we went through several ways to resolve ownership issues:

We can take and return ownership of values without cutting the ownership flow.
We can pass a copy of the value avoiding the ownership move.
We can share ownership using reference counting.
We can give access to values without renounce to ownership via borrowing using references.
And we can refactor the code to remove the ownership transfer rethinking the function call order or manually inlining code.

Witch option we should pick? Well, like many interesting answers in life, it begins with the word: depends. There is no magic rule to follow any time, because the selected option would depends on the problem you have into hands.

As general guidance immutable and mutable references are usually the most flexible option, because allow access to a value without transferring ownership, avoiding the need for cloning or moving data. One typical exception are the constructors where taking ownership of the values is usually the best option if we want to keep the ownership flows simple and understandable.

struct Person {
    name: String,
}

impl Person {
    fn new(name: String) -> Person { // instead of: fn new(name: &String) -> Person
        Person {
            name, // instead of: name: name.clone()
        }
    }

    fn get_name(&self) -> &String { // instead of: fn get_name(&self) -> String
        &self.name // instead of: self.name.clone()
    }
}

The main advantage to make an interface that returns references is we left the callers and the client code decide if the reference will suffice or if they need to clone the value instead.

fn main() {
    let person = Person::new(String::from("John"));

    let name = person.get_name();

    let other_john = Person::new(name.clone());

    println!("{} {}", person.name, other_john.name);
}

For other more complex interactions where we need to share some data or custom type across the program logic we should consider the Rc<T> approach. And if we are follow a more functional approach where immutability is central, make interfaces that returns cloned owned value instead of references would help.

We must remember that, from a static analysis perspective, memory management in Rust is enforced syntactically⁴. The compiler relies solely on the code’s structure and ownership rules (like moves, borrows, and lifetimes) to statically validate memory safety, even though memory operations are inherently dynamic at runtime.

This strict compile-time checking is a key contributor to Rust's learning curve. We're not just learning ideas like ownership and borrowing—we have to write code in a way that makes the borrow checker happy, which often requires adjusting code that seems correct or restructuring logic to meet the compiler’s expectations. While this can feel restrictive, it reflects Rust’s core trade-off: rejecting some valid patterns upfront to eliminate memory vulnerabilities entirely.

Final Words

Starting with a simple 'use of moved value' scenario, we explored various ownership-related concepts and techniques. We also examined ways to relax or even defy the static rules with dynamic replacements. I'm confident that we've now built a practical understanding of how the ownership system works, which is essential for tackling more complex scenarios. Stay tuned!

Licensed under CC BY-SA 4.0.

References:

YouTube: 5 Deadly Rust Anti-Patterns to Avoid.

Book: Idiomatic Rust by Brenden Matthews - Chapters 1 and 2.

Book: Rust for Rustaceans by Jon Gjengset - Chapters 1 and 3.

There are two exceptions to this: the use of unsafe code to bypass the mutability restrictions and the use of shareable mutable containers Cell, RefCell, and OnceCell, which allows us to mutate the data inside an immutable container. ↩
Internally, Rc uses PhantomData, a zero-cost abstraction, to represent ownership without storing an actual instance of T. Including PhantomData allows the compiler to track ownership and enforce type relationships at compile time without spend more memory. ↩
The Rc solution is more subtle because it implies the pass-by-value of the smart pointer itself instead of the wrapped value. ↩
While Rust’s memory management is enforced through code structure (e.g., moves, borrows, and lifetimes), ownership itself is a semantic concept. Rust’s compile-time enforcement is rooted in memory safety semantics, even though it relies on syntactic patterns to express those rules. ↩

Smalltalk meets Forth: Episode I

Jorge Luis Perez — Thu, 06 Feb 2025 00:38:42 +0000

The idea is simple: build a Forth interpreter in Smalltalk in a series of posts and learn some Forth and Smalltalk in the process.

For this first session we would like to end with a fully working Forth REPL with at least some of the basic math words implemented. Also, a pretty basic error handling would be good to have from the beginning.

There are several Smalltalk flavors to choose from, but I share Cuis-Smalltalk’s love for small, simple, and understandable things. So, ‘Cuis, I choose you!’ 🐹

Another tool for the journey is the Forth standard. I aim to use its references, jargon, and overall organization to keep the interpreter as close to the standard as possible, while still allowing room for more creative or implementation-specific words.

One advantage we have is there are many Forth implementations out there, so we can use them as a reference of the word's behaviors and outputs on the REPL, GForth and SwithForth would be a good source of inspiration.

I prefer to introduce the Forth concepts as we need it, but a little introduction will put us all on the same page.

Forth

Forth is a stack-based, concatenative programming language and environment that is designed for simplicity and extensibility. Stack-based means that Forth uses a stack to hold data and control flow, operations are performed by pushing and popping values from the stack. We can think in Forth as a thin abstraction over a stack machine.

Concatenative means that programs are composed of sequences of words that can be combined together. Each word can be defined in terms of other words, allowing for a high degree of modularity and reuse.

Forth typically combines a compiler with an integrated command shell, where the user interacts via subroutines called words. Words can be defined, tested, redefined, and debugged without recompiling or restarting the whole program. All syntactic elements, including variables, operators, and control flow, are defined as words. A stack is used to pass parameters between words, leading to a Reverse Polish Notation style.

From Wikipedia

Similar to Smalltalk, which has the strong metaphor ‘Everything is an object’, Forth embodies the idea that ‘Everything is a word’.

The REPL

One thing I really enjoy about Smalltalk is its level of interactivity; you have inspectors, explorers, and debuggers that allow you to have a programming conversation with the environment. I want to keep the journey as conversational as possible, so we need to start by creating a simple REPL where we can experiment with our Forth implementation as we build it.

The good news is that the Cuis environment already has a similar editor we can use as a reference to understand how it’s built. The Text Editor offers more functionality than a REPL, so we can think of a REPL as a limited version of a Text Editor, with some features intentionally restricted. It might be a bit much, but the structure and most of the behavior are useful for our case. I think it could be a good place to start.

Exploring the Text Editor using the halos, we learn that the main Morphic structure of the Text Editor is:

SystemWindow-> LayoutMorph -> TextModelMorph -> InnerTextMorph

The halos in Smalltalk offer an interactive way to explore graphical objects. By clicking on halos, you can inspect graphical object properties and relationships, providing a hands-on approach to understanding the system.

After spending some time tinkering and winging it with browsers, explorers and inspectors, I found that the behavior we need to specialize is mostly within the InnerTextMorph. Also, we need to make a little adjustment to TextModelMorph to use the specialized InnerTextMorph.

I create ForthTextModelMorph and ForthInnerTextMorph classes which are subclasses of TextModelMorph and InnerTextMorph respectively.

TextModelMorph subclass: #ForthTextModelMorph
   instanceVariableNames: ''
   classVariableNames: ''
   poolDictionaries: ''
   category: 'CuiForth-Morph'

InnerTextMorph subclass: #ForthInnerTextMorph
   instanceVariableNames: ''
   classVariableNames: ''
   poolDictionaries: ''
   category: 'CuiForth-Morph'

It is necessary to set the inner morph class for ForthTextModelMorph.

ForthModelMorph>>innerMorphClass
    ^ ForthInnerTextMorph

This step determines that the inner text handling behavior of ForthModelMorph will be managed by ForthInnerTextMorph.

To integrate the entire morph structure, we introduce the ForthREPL class. This is the primary class responsible for running the REPL, initializing the system, and holding the Morphic structure.

Object subclass: #ForthREPL
    instanceVariableNames: 'window'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'CuiForth-Window'

ForthREPL>>initialize
    | forthTextModelMorph forthTextModel |
    super initialize.
    forthTextModel := ForthTextModel new.
    forthTextModelMorph := ForthTextModelMorph new.

 "Connnect the text models"
 forthTextModelMorph model: forthTextModel.

 "The Forth model morph will use all the available width and heigth"
 forthTextModelMorph layoutSpec
     proportionalWidth: 1.0;
     proportionalHeight: 1.0.

 "Main window configuration"
 window := SystemWindow new
     setLabel: 'CuiForth REPL';
     model: forthTextModel;
     addMorph: forthTextModelMorph.

The structure ends like this:

SystemWindow -> LayoutMorph -> ForthModelMorph -> ForthInnerTextMorph.

Another little method to open the REPL could be handy.

ForthREPL>>open
    window openInWorld.

The ForthInnerTextMorph is where we need to add our keystroke handle logic. The most important thing is to handle the return key to process the words at the current line. The rest of the logic is to customize the text editor to behave like a REPL.

ForthInnerTextMorph>>keyStroke: aKeyboardEvent
    aKeyboardEvent isReturnKey ifTrue: [
        editor processWords
    ].

    "We don't want backspace to go back to the previous line"
    self ignoreBackspaceWhenLineIsEmpty: aKeyboardEvent.

    "For now, ignore the up and down arrow keys;
       they could serve later to navigate previous commands"
    self ignoreUpArrowKey: aKeyboardEvent.
    self ignoreDownArrowKey: aKeyboardEvent.

    "Let the normal keystroke processing continue"
    super keyStroke: aKeyboardEvent.

Notice that for word processing ForthInnerTextMorph delegates this responsibility in its internal collaborator editor (ForthEditor). This separation of concerns might allow us to reutilize the editor with other Morphic configuration.

TextEditor subclass: #ForthTextEditor
    instanceVariableNames: 'extractedWords interpreter'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'CuiForth-Text'

Notice that the editor knows the interpreter. The class of the text editor is configured in the text model class:

TextModel subclass: #ForthTextModel
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'CuiForth-Text'

ForthTextModel>>editorClass
    ^ ForthTextEditor

The main responsibility of the ForthEditor is handled by its processWords message. This method is designed to extract the words from the current line (after the return key is pressed), pass those words to the interpreter, and display the interpreter’s output to the user. For now, a placeholder implementation that always responds with ‘ok’ for any input will suffice.

ForthEditor>>processWords
    self addString: ' ok'

Let’s open the REPL and do some manual testing.

Until now, I've used a more exploratory programming style, checking changes in the Workspace. For the remaining features, I followed a mostly TDD approach, but I don’t think that’s the best flow for the article — let me continue with a more descriptive tone.

With the REPL ready we can start to implement Forth features.

A Note about the REPL

A REPL is the usual way to interact with Forth, giving quick feedback as you type. But in Smalltalk, the go-to tool for playing with code is the Workspace. It’s like a live text editor where you can write, run, and tweak code snippets on the spot. We’ll explore that possibility for our Forth interpreter later.

The Stack

As we said, Forth is stack-based. In general, it has two main stacks: the data stack and the return stack. The former holds data items, and the latter manages return addresses for control flow. Let’s start with the former.

We only need a classic stack, with a pretty printString method to use later.

Object subclass: #ForthDataStack
    instanceVariableNames: 'collection'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'CuiForth-Interpreter'

ForthDataStack>>initialize
    collection := OrderedCollection new.

ForthDataStack>>pop
    collection ifEmpty: [ StackUnderflow signal ].
    ^ collection removeLast

ForthDataStack>>push: anElement
    collection addLast: anElement

ForthDataStack>>printString
    | count items |
    count := collection size asString.
    items := collection inject: '' into:
        [ :acc :item | acc, item printString, ' '].

   ^ ('<', count, '> ', items)

The most interesting thing here is that the stack signals a StackUnderflow if we try to pop an element when the collection is empty. In Forth, all parameters are passed via the stack, with words operating by popping and pushing data to and from it. If a word needs a parameter that isn’t on the stack, we definitely want to know.

The Interpreter

Finally, we arrive at the core of the project: the Forth interpreter. First, we’ll discuss the general logic, followed by some interesting implementation details.

Object subclass: #ForthInterpreter
    instanceVariableNames: 'dataStack display'
    classVariableNames: ''
    poolDictionaries: ''
    category: 'CuiForth-Interpreter'

The dataStack internal collaborator is self-explanatory: it holds an instance of the ForthDataStack, as discussed earlier. The display is where printable messages generated during the interpretation process are stored. The editor object will use this to show messages to the REPL user.

The interpreter is responsible for implementing all Forth words. To organize them, I’ve used the standard group names as message categories. The naming conventions follow the standard as the main reference.

Forth standard categories into messages categories:

The main message of the interpreter is execute:

ForthIntepreter>>execute: textWords
    | tokens |

    self clearDisplay.

    tokens := self tokenize: textWords.

    tokens do: [ :token |
       [ token execute: self ]
           on: ForthError
           do: [ :error | ^ self display: error description ]].

    self displayOk

The method receives a line of text (the words), tokenizes it, and then processes each token one by one. Tokenization in Forth refers to splitting the line of text into individual words (or tokens), which are separated by whitespaces. Each token is treated as an atomic command or operand, and the interpreter executes these in sequence. This straightforward process is key to how Forth operates, where each word in the code is treated as a command, making the interpreter’s design simpler and more direct.

Forth’s tokenization typically does not involve complex parsing rules; rather, it focuses on identifying individual, space-separated sequences of characters that represent commands, variables, or numbers: words in Forth parlance. In Forth everything is a word.

ForthInterpreter>>tokenize: aString
    | textWords |
    textWords := aString substrings.

    ^ textWords collect: [ :textWord |
        ForthToken newFrom: textWord ]

This method takes a string, splits it into words using substrings, and turns each word into a ForthToken. The ForthToken class is the base class for all tokens, and it knows how to create the right type of token from each word.

To do this, it goes through its subclasses until it finds one that matches the string. Each subclass knows how to check if it matches a given string.

ForthToken class>>newFrom: aStringWord
    self tokenTypes do: [ :tokenType |
        tokenType ifMatch: aStringWord eval: [ :token | ^ token ] ].

ForthToken class>>tokenTypes
    "Return all token types in tokenization order"
    ^ self subclasses sort:
        [ :a :b | a tokenizeOrder < b tokenizeOrder ]

After tokenization, the interpreter executes each token one by one. One important thing to note in ForthInterpreter>>execute: is the double dispatch happening in this line:

ForthIntepreter>>execute: textWords
    ...
    tokens do: [ :token |
        [ token execute: self ] "<- Double dispatch"
    ...

In this design, each token knows how to execute itself, sending the appropriate message to the interpreter, which holds the implementation for each word. The tokens inherit the following method:

ForthToken>>execute: aForthInterpreter
    aForthInterpreter perform: self value.

The perform: message in Smalltalk is a powerful metaprogramming feature that allows you to send a message to an object dynamically at runtime. It takes a symbol as its parameter and sends the corresponding message to the receiver. This is especially useful in cases like our Forth interpreter, where the message to be send is determined at runtime.

In the context of our interpreter, the value of a token is its representation as a Smalltalk symbol. For example, a token value #plus represent the addition operation in Forth. The exact message that will be sent is based on the token’s symbolic value, determined during tokenization.

MathSymbolToken>>newFrom: aString
    ^ self new 
        value: (self mathSymbols at: aString) asSymbol

Some tokens include a dictionary that maps strings to their corresponding symbols. These symbols are then converted into messages sent to the interpreter using the perform: message, as shown earlier. For example, in the MathSymbolsToken class:

MathSymbolToken>>mathSymbols
   ^ `Dictionary newFrom: {
       '+' -> #plus.
       '-' -> #minus.
       '*' -> #star.
       '/' -> #slash.
   }`

We don’t want to reevaluate the dictionary every time. By surrounding the expression with backticks, we create a compound literal. This approach ensures all components of the compound literal are resolved when the code is compiled, rather than at runtime, acting like a constant. All components of a compound literal must be known when the code is compiled.

Looking back to the tokenization part of the process, there is an interesting thing happening in ForthToken class>>newFrom: method, there is no return except for the one in the block passed as argument to ifMatch:eval message.

ForthToken class>>newFrom: aStringWord
    self tokenTypes do: [ :tokenType |
        tokenType ifMatch: aStringWord eval: [ :token | ^ token ] "<--" ].

Blocks in Smalltalk are full closures. This means they capture not only the values of variables from their defining context but also the entire execution environment, including the return point of the method where they are defined. Additionally, blocks support lazy evaluation, meaning the execution is deferred until explicitly evaluated. What makes them full closures is their ability to maintain this environment even when the block is executed in a different scope, which allows for non-local returns and the preservation of local state across different contexts.

MathSymbolToken class>>ifMatch: aString eval: aTokenBlock
    self mathSymbols at: aString ifPresent:
        [ :symbol | aTokenBlock value: (self newFrom: symbol) ].

In the case of ForthToken>>newFrom:, the ^ token inside the block allows the ifMath:eval method to terminate immediately and return the desired token as soon as a match is found. When the aTokenBlock block is evaluated with the matched token passed as an argument via the value: message in the ifMatched:eval: context, the ForthToken class>>newFrom: completes and returns.

ForthToken class>>newFrom: ->
    ...
    tokenType ifMatched:eval: [ :token | ^ token ] ->
        ...
        aTokenBlock eval: token "returns from newFrom:"

Blocks are central to Smalltalk’s language design. They enable message-based control flow (without the need for if statements), iterators (such as select:, collect: and others), lazy evaluation, non-local returns, error handling, and programming techniques like continuation passing style.

Now we have covered the main functionality of the interpreter, and some interesting details. Let’s check the word’s implementation.

The Math

To make basic arithmetic work in our interpreter, the first thing to handle is numbers — positive and negative integers, to be specific. Earlier, we saw how tokens are recognized and how they handle their own execution. The default behavior for all tokens looks like this:

ForthToken>>execute: aForthInterpreter
    aForthInterpreter perform: self value.

That’s okay for most words in Forth, but numbers require specialized behavior:

NumberToken>>execute: aForthInterpreter
    aForthInterpreter pushToDataStack: self value.

Number words act as arguments for other words. Since Forth is stack-based, all arguments are pushed to and popped from the stack. So, when a number token reaches the interpreter, it needs to be pushed onto the data stack.

To add numbers, we push two numbers onto the data stack and execute the + word. We already know that the math + word is mapped to the #plus symbol in a MathSymbolToken object.

MathSymbolToken>>mathSymbols
    ^ `Dictionary newFrom: {
        '+' -> #plus.
        '-' -> #minus.
        '*' -> #star.
        '/' -> #slash.
   }`

For this case the ForthToken>>execute inherited behavior is exactly what we need. However, the interpreter must know how to respond to the dynamically sent plus message.

ForthInterpreter>>plus
    | first second |
    first := dataStack pop.
    second := dataStack pop.
    dataStack push: second + first.

As we can see, the method is pretty straightforward: it pops the two necessary arguments, performs the calculation, and pushes the result back onto the stack. All other arithmetic messages are resolved in the same way, with the only slightly special case being the slash message.

ForthInterperter>>slash
    | first second |
    first := dataStack pop.
    second := dataStack pop.

    (first = 0) ifTrue: [ DivisionByZero signal ].

    dataStack push: second / first

The method checks division for zero after pop the two arguments. Why is that? because this behavior is observed in the reference implementations.

One neat effect of Smalltalk’s features is that our Forth math implementation supports fractions out of the box.

With basic arithmetic working, let’s add some programming tools.

The Tools

In Forth jargon the dot words are the ones that Forth programmers use primarily for debugging and displaying data. The term dot words is derived from the fact that many of these words begins with a dot character. The general purpose of dot words is to facilitate interaction with the stack.

The first is the dot word:

ForthInterpreter>>dot
    self displayAppend: dataStack pop printString

This word pops the top element from the stack and prints it.

Printing the top element of the data stack with the dot word.

The dot word is considered part of the core words in the standard. It is commonly used at the end of a one-liner to check results.

Another useful tool is the dot S word, which copies and displays the values currently on the data stack.

ForthInterpreter>>dotS 
    self displayAppend: dataStack printString

Here, we simply rely on the printString message of the data stack, as discussed in the stack section earlier.

In the tokenization process, the DotWordToken is responsible for mapping the string word to its symbol representation

DotWordToken class>>dotWords
    ^ `Dictionary newFrom: {
        '.s' -> #dotS.
        '.' -> #dot.
    }`

With these two dot words, we have a basic way to inspect the data stack.

Error Handling

We don’t need any sophistication in error handling for now. We just need to create a basic error hierarchy to represent interpretation errors, catch that during the execution of words, and provide an error description to the user when necessary.

ForthIntepreter>>execute: textWords
    ...
    tokens do: [ :token |
        [ token execute: self ]
            on: ForthError
            do: [ :error | self display: error description ]].

The only atypical thing is we specialize the doesNotUndestand: message of the interpreter. The doesNotUndestand: message is sent by the virtual machine to the receiver object when the method lookup fails to find a method for the sent message. It is the virtual machine giving the receiver object the chance to decide how to respond to an unexpected message.

The doesNotUndestand: message is one of those great ideas built into Smalltalk. It is considered a door to metaprogramming because we can reflect over the aMessage object and respond in very dynamic ways. However, for this case, we wanted something much simpler.

ForthInterpreter>>doesNotUnderstand: aMessage
    UndefinedWord signal

Since the interpreter object is the receiver of the Forth words, we want the REPL to display the message ‘Undefined word’ for non-implemented words, rather than triggering the typical Smalltalk behavior of popping up a debugger.

For all other errors not subclassed from ForthError, we wanted Smalltalk’s normal behavior.

The Editor

To complete the circle of this first iteration of the Forth interpreter, we need to finalize the editor implementation. Recall that when the user presses the return key in the REPL, the processWords message is send to the editor:

ForthEditor>>processWords
    self extractWords;
        executeWords;
        printMessageToUser

processWords is implemented as a cascade of three private methods, each contributing to the handling of user input.

ForthEditor>>extractWords
    | textWords |

    textWords := model actualContents
        copyFrom: self currentLine first
        to: self currentLine last.
    
    extractedWords := textWords asString

The extractWords message retrieves the string of words from the text model and stores it in the extractedWords instance variable, which serves as a pivot for the word-processing logic.

ForthEditor>>executeWords
    interpreter execute: extractedWords

This simply sends the execute message to the interpreter, passing the freshly extracted words string.

ForthEditor>>printMessageToUser
    self addString: interpreter displayMessage

The final step is to display feedback to the user in the REPL by printing the appropriate message from the interpreter.

With the editor logic gluing the REPL and the interpreter: The circle is now complete.

Moving Forward

We’ve covered a lot of ground in this article — from crafting a REPL in Smalltalk’s UI to building a Forth interpreter with basic arithmetic, programming tools, and error handling. The effort pays off: it gives us a solid structure to expand the interpreter and experiment with new features in future episodes.

In the next part, we’ll keep adding features to the interpreter — probably diving into word definitions and conditionals. If you’re curious, make sure to follow along!

I left you a nerdy-motivational fact about Forth:

The Forth programming language was used in the production of Star Wars: Episode IV — A New Hope. Specifically, it was used to control the Dystraflex motion control system, which was created by John Dykstra and his team at Industrial Light & Magic. This system was instrumental in creating the complex and precise camera movements required for the space battle scenes and the trench run sequences on the Death Star.

From Wikipedia

Repository: https://github.com/jolisper/Cuis-Smalltalk-CuiForth

Smalltalk: Conceptual Integrity in Action

Jorge Luis Perez — Mon, 09 Dec 2024 20:45:38 +0000

One of the most eye-opening and influential ideas in my journey as a programmer was the concept of ‘conceptual integrity’, introduced by Fred Brooks in The Mythical Man-Month in his essay Aristocracy, Democracy, and System Design.

It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

Fred Brooks

In a nutshell, conceptual integrity consists of a set of well-related, composable concepts and the relationships between them, forming a kind of conceptual algebra.

When we introduce a new concept that doesn’t integrate well with the others, the conceptual algebra suffers in the form of increased complexity. Special or exceptional cases must be considered, which limits the expressiveness of the algebra and raises the cognitive load for those who have to play with it. Just one poorly selected concept affects the whole.

In a way, what Brooks is suggesting is that design lives in the constraints we impose on the material we work with. This is especially true in software development.

Unlike other forms of human craftsmanship, software has more flexible constraints. For example, when building a bridge, we encounter hard limits imposed by factors like gravity, wind, vibrations, and material strength — all of which must be calculated and accounted for before construction even begins.

Software is, by nature, a very malleable creature, with its hard limits mostly imposed by hardware: the computing power, the volatile and persistent storage, and the capacity of the network connection¹.

Another point where the analogy between building software and building things in the physical world is also broken is at how those different creations handle the pass of time and the changes, and the expectations we have about that.

For the things built in the physical world, in general, we expect that those things would be more or less durable and maintain their original characteristics until we finish to used them. No one expects that a bridge automatically gets wider because the traffic that passes over it increases substantially or shrinks when the traffic decreases. That is exactly what we expect from software, we want it to change and adapt automatically. Designing software to show resilience to changes over time is apparently an important feature to consider.

If we build software like we build bridges, we end up with a piece of software very hard to change and doomed to be maintained until someone with the authority (but probably without the knowledge) decides to destroy it and build it again. Any resemblance with reality is purely coincidental.

Designing by Subtraction

Subtracting the superfluous to reveal the essence, or the soul, of a creation is a well-known process in arts.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

Saint-Exupéry

Another phrase, attributed to a multi-talented artist primarily known as a sculptor, captures this idea pragmatically.

“I saw the angel in the marble and carved until I set him free.”

Michelangelo Buonarroti

I think that we can follow a similar process for software. While the static nature of sculpture might not be a good analogy for a running program, the idea of revealing a design that’s already present in the problem domain sounds like a good guideline to me. The attitude of unveiling a design instead of trying to impose one on the problem should distance us from the root of all evils in programming.

Premature optimization is the root of all evil (or at least most of it) in programming.

Donald Knuth

To achieve that in software, we should model the problem at hand in a way that no artificial complexity is added to the solution model. Much like a sculptor carving away marble to reveal the form within, we should aim to reduce artificial complexity to a minimum during iterations in software design, refining our solution until the true essence of the problem we’re addressing is revealed.

The Problem of Computing Things

Alan Turing (left) and Alonzo Church (right)

When searching for the roots of computation, we could find two seminal and isomorphic works: Alan Turing’s Turing Machine and Alonso Church’s Lambda Calculus. Discussing these in detail would require an entire article, but it is important to note that each has its own computation metaphor.

Turing’s approach is more mechanical, with an abstract machine manipulating symbols on an infinite tape, while Church’s Lambda Calculus expresses computation through function abstraction and application, like an ancient ancestor to Lisp.

Smalltalk also has its own computation metaphor, where the message-passing concept plays a fundamental role. Biological information processing was the source of inspiration for Alan Kay², the way that cells interchange information through protein messages and influences the behavior of the receiving cell is the base model for Object Oriented Programming³.

“The shift in point of view here is […] if you take things like clocks they don’t scale by a factor of a hundred very well. Take things like cells they not only scale by a factor of a hundred but by factors of trillion, and the question is, how do they do it, and how might we adapt this idea for building complex systems.”⁴

Alan Kay at OOPSLA 1997

The core idea Kay is illustrating is that biological systems offer a model of scalability and adaptability that can be a useful analogy for thinking about how we design complex software systems.

“The ARPANET, of course, became the Internet, and from the time it started running — just around 1969 or so — to this day, it has expanded by about a factor of a hundred million. […] There is not one line of code in the Internet today that was in the original ARPANET. […] This is a system that has expanded by a hundred million, has changed every atom and every bit, and has never had to stop. That is the metaphor we absolutely must apply to what we think are smaller things.”

Alan Kay at OOPSLA 1997

Kay provides the Internet as a practical illustration of how to model systems that mirror the scalability of natural systems. His design of OOP, inspired by biological processes, shares similarities with the modular, decentralized, and dynamic nature of the internet, where objects interact through message-passing much like how nodes in a network communicate.

Communicating Objects

In Smalltalk, if we want that something happens we must follow the form:

Object message

Even arithmetic, string concatenation, and control flow follow this pattern. This is where the expression In Smalltalk, everything is an object finds its deeper meaning. This idea isn’t just a declaration; it’s a practical reality. Everything is an object not because some gods on Olympus declared it, but because the only way to perform any computation is by sending a message to an object — period.

For instance, the sum of 2 integers is resolved by sending a message + to the left number, with the right number passed as the message’s argument. Sentences in Smalltalk ends with a dot, similar to a semicolon (;) in other languages; the result of the evaluation is printed after the dot.

2 + 2. 4

This marks a fundamental distinction from the vast majority of mainstream programming languages, where such computations are hardcoded into the language’s syntax, even in those that refer to themselves as object-oriented.

But that decision comes with a cost: Smalltalk loses the familiar operator precedence found in mathematical expressions.

2 + 2 * 3. 12

We must be explicit to ensure the common precedence of mathematical operations.

2 + (2 * 3). 8

Smalltalk sticks to its notion of computation and doesn’t break the object-message computation form just to have a more convenient mathematical precedence. It’s as if Smalltalk were telling us, ‘Sure, having math expressions with well-known operator precedence sounds good, but it doesn’t mesh well with my more important concept of message-passing computation. I’d rather leave that aside.’

If Smalltalk were to incorporate mathematical expressions with standard operator precedence, it would introduce a special case: math expressions would function as a sublanguage within Smalltalk — a kind of DSL embedded in the main language — increasing the complexity of the implementation, in particular the compiler, which would have to handle arithmetic operators and its precedence. In the current solution, however, the compiler remains completely agnostic to math operators.

More importantly, including mathematical expressions with standard operator precedence would break the message-passing computation form, affecting the entire conceptual algebra just to incorporate an idea that seems good at first glance. Leaving this idea aside preserves conceptual integrity, resulting in a terser syntax with no special cases.

In Smalltalk, a number is just like any other object that needs to receive a message to make a computation. This beautifully reminds me of another passage of the same essay from Brooks.

Simplicity and straightforwardness proceed from the conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics.

Fred Brooks

Even more interesting than arithmetic is the case of control flow. In most programming languages we must use reserved words, such as if-then-else blocks or similar to control the flow of a program.

if condition then  
 ...  
else  
 ...  
end

That is not the case with Smalltalk. Staying true to its computing model, there is no special syntax for controlling program flow — just plain old message sending to objects.

condition ifTrue: [ ... ] ifFalse: [ ... ]

Here, the message name is ifTrue:ifFalse: which receives two blocks: one for the true case and another for the false case. Blocks represent a piece of code—essentially, a set of object collaborations in object-oriented parlance—and they allow us to defer code execution until needed by sending the message value to the block. In this case, only one of the blocks will be executed, depending on the condition.

A key point that’s easy to overlook is that the selection of which block to execute depends on the class of the condition object. In Smalltalk, the method ifTrue:ifFalse: is defined abstractly in the Boolean class but is implemented differently in its concrete subclasses, True and False.

True>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock  
   ^ trueAlternativeBlock value

False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock  
   ^ falseAlternativeBlock value

This beautiful implementation illustrates the essence of object-oriented programming: when a message is sent to an object, it is the object itself that determines which method will be used to respond⁵. It’s a fully polymorphic way of understanding control flow.

Completely aligned with Brooks’ ideas, we can find the following paragraph in the book Smalltalk-80: The Language and Its Implementation, also known as The Blue Book.

Smalltalk is based on a small number of concepts […] Due to the uniformity with which the object-message orientation is carried out in the system, there are very few new programming concepts to learn in order to understand Smalltalk.

From Blue Book

Encapsulation

“Once you have encapsulated in such a way that there is an interface between the inside and the outside it is possible to make an object act like anything, and the reason is simply this, that what you have encapsulated is a computer.”

Alan Kay at OOPSLA 1997

Deeply connected to the idea of message-passing computation is the concept of encapsulation. In fact, encapsulation, in some sense, enables message-passing computation to exist: encapsulation creates a boundary between the inside and outside of an object, and it is this boundary that demands an interface to make computation possible. That interface, in turn, allows the object to decide how to respond internally when it receives a message from the outside.

Thinking of objects as tiny, specialized computers communicating with each other over a network is a powerful analogy. When one computer on the internet communicates with another, it follows a common message protocol to exchange information but doesn’t permit direct access to its volatile or persistent storage. Why? Because allowing an external computer to write directly to its storage would lead to chaos, stripping away its autonomy. This loss of control would break the system’s ability to make decisions, compromising the very foundation of message-passing computation.

A DTO⁶ is a typical example of what an object is not. Being completely open to the outside, it loses its ability to decide what to do, breaking the principle of encapsulation. This unrestricted external access contradicts the autonomy of true objects. A DTO is more like a specialized data structure, similar to a dictionary, that merely mimics an object but lacks its essential characteristics.

Encapsulation and message-passing computation reinforcing each other in an algebraic form that preserves the system’s conceptual integrity. By conceptualizing objects as autonomous entities, much like specialized computers, we can design modular systems that exhibit uniformity from their most basic components to the most complex constructs.

[In] Smalltalk, which is built on the model of communicating objects, […] large applications are viewed in the same way as the fundamental units from which the system is built.

Dan Ingalls in Design Principles Behind Smalltalk

Late Binding

Every time we send a message to an object, the Smalltalk virtual machine runs an algorithm called method lookup, which locates the appropriate method based on the receiver object and message. A key concept here is that the message and the method are mediated by a kind of dynamic switch-case mechanism embedded in the virtual machine for our profit, effectively embodying the fundamental theorem of computer science that states:

"We can solve any problem by introducing an extra level of indirection."⁷

This mechanism links the message to the actual implementation code — the method. The What and the How are decoupled. This conceptual and practical distinction, between the What and the How — between the intention and the realization — is incredibly powerful. Combined with the ubiquity of message-passing computing style, it offers flexibility in virtually every computation we perform.

In Smalltalk sending a message is a way to express choices.

myObject open

When a message like open is sent to myObject, Smalltalk’s method lookup process dynamically determines which implementation of open to execute, depending on the class of myObject. Whether myObject is a file, a window, or a tool, each will interpret and respond to the open message according to its specific behavior.

Smalltalk provides a […] cleaner solution: it sends the name of the desired operation, along with any arguments, as a message to the [object], with the understanding that the receiver knows best how to carry out the desired operation.

Dan Ingalls in Design Principles Behind Smalltalk

At OOPSLA 1997, Alan Kay uses the Japanese concept of ma to underscore a process-oriented perspective on objects — one that focuses on the space for dynamic interactions and responses within the message-passing model.

“Ma is the stuff in-between what we call objects. It’s the stuff we don’t see, because [in the western culture] we’re focused on the nounness of things rather than the processness of things.”

Alan Kay at OOPSLA 1997

Ma refers to an intentional gap or interval that allows space for the interpretation of meaning. Sending a message involves more than just a direct action — there’s a conceptual space where the object decides how to respond.

The separation of What from How enables objects to autonomously determine their responses. Smalltalk dynamically aligns intention with execution, holding off the decision of which implementation to execute until the last moment.

“One of the great principles of computer science it’s laziness or whatever you call it, late binding. Hold off decisions when you can.”

Donald Knuth

Meta-System

“The more the language can see its own structures the more liberated you can be from the tyranny of a single implementation.”

Alan Kay at OOPSLA 1997

One of the effects of applying the metaphor of communicating objects consistently across Smalltalk is that the language constructs themselves become part of the universe of objects available to us as Smalltalk programmers. And it is exactly this effect that was taken advantage of to create all the visual tools that are part of a typical Smalltalk distribution.

Listing the OrderedCollection class selectors in the accessing category.

Debuggers, inspectors, explorers, and browsers in Smalltalk are built with the language itself, utilizing its extensive reflexivity and metaprogramming capabilities.

Browsing the OrderedCollection class, listing its accessing methods.

Additionally, the visual components of Smalltalk user interface are Smalltalk objects, which means we can inspect, explore, and debug those components just like any other object⁸.

Exploring a text editor

Every component accessible to the user should be able to present itself in a meaningful way for observation and manipulation.

Dan Ingalls in Design Principles Behind Smalltalk

What is even more surprising is that this remarkable level of reflectivity and metaprogramming occurs in an open and live object environment. Open means that all the objects constituting the base system are accessible for our inspection and modification; our code operates on the same level as the base system. Live means that we can program, inspect, and modify while the objects are running, freeing us from the conventional edit-compile-run-stop loop.

Smalltalk people call that the meta-system⁹. The meta-system empowers users to understand and modify the system itself, turning users into creators. Kay envisioned meta-systems as tools to encourage users to not just work with data but to reshape their tools and frameworks as they go. In this view, the user isn’t just operating within a closed system but actively extends, refines, and redefines the system’s boundaries.

“I think one of the things we liked the most about Smalltalk was not what it could do, but the fact that it was such a good vehicle for bootstrapping the next set of ideas we had about how to do systems building.”

Alan Kay at OOPSLA 1997

Final Words

Smalltalk is to me one great example of what we can achieve in system building if we actively follow the concept of conceptual integrity.

As we’ve seen, Smalltalk is more than just a programming language — it’s an entire interactive programming environment, grounded in a small, interwoven set of concepts applied recursively across both language and system levels. Even more, Smalltalk offers a unique approach to thinking about computation itself. Its metaphor, everything is an object, is applied uniformly across all areas, reinforcing a powerful and cohesive model of computation.

Smalltalk, as designed by Alan Kay and his team¹⁰, aimed to deliver this level of integrity by building a cohesive environment where all components, from the language syntax to the user interface, consistently reflect the object-oriented paradigm.

By conception, Smalltalk is a tool meant to release the creativity of those who use it, a standpoint for bringing the next big set of ideas about system building. In the words of Alan Kay himself:

[Smalltalk is] an attempt to give the world a bootstrapping mechanism for something much better than Smalltalk.

Alan Kay at OOPSLA 1997

Licensed under CC BY-SA 4.0.

Footnotes:

[1]: Nowadays with the access to cloud computing those limits are even more relaxed. (back)

[2]: It’s not a coincidence that those ideas come from Alan Kay; he majored in biology focused on both cell metabolism and larger scale morphogenesis and minored in mathematics centered on abstract algebras. (back)

[3]: Alan Kay has expressed regret for coining the term Object-Oriented Programming (OOP). He has criticized himself, saying he should have used a more process-oriented term, as the most important concept is what happens between objects. (back)

[4]: A quote from Alan Kay: “In many talks, long ago, I have shown a picture with the title “From Gears To Biology” as a metaphor for a qualitative shift in thinking about computer systems — from early-bound, tightly coupled rather small mechanisms — like clocks — to late-bound, loosely coupled rather large mechanisms — like living organisms. In computing, this happened within a single lifetime, and many parts of computing are still stuck in the earlier metaphor.” (back)

[5]: In Smalltalk, comparison messages like >, < and = return instances of the True or False classes. (back)

[6]: Data Transfer Object (DTO): Commonly used in many languages, DTOs are objects meant to transport data between systems or layers in an application. They typically have getter and setter methods but lack significant logic, they expose all their fields through public methods. (back)

[7]: Except for the problem of too many levels of indirections. (back)

[8]: Morph is the top-level class for any visual component in Smalltalk (Squeak family). Paraphrasing Smalltalk’s own metaphor: every visual component is a Morph. (back)

[9]: A meta-system is a computational system that has as its domain another computational system called its object domain. (back)

[10]: Mainly Dan Ingalls and Adele Goldberg among others. Dan Ingalls was instrumental in implementing the early versions of Smalltalk, while Adele Goldberg was influential in documenting and promoting its use. (back)

References:

The Mythical Man-Month

Alan Kay at OOPSLA 1997 — The computer revolution hasn’t happened yet (youtube.com)

Donald Knuth: Premature optimization is the root of all evil | Donald Knuth and Lex Fridman ()youyoutube.com)

‘Computing is not about clocks, it’s about biology’. How come the essence of computing is more about the way living organisms evolve? — Quora

Hernan Wilkinson at FAST 2014 — How Smalltalk Affects Thinking (youtube.com)

Aprendiendo Smalltalk con Hernan Wilkinson

Glenn Vanderburg — Real Software Engineering (youtube.com)

Stef’s Free Online Smalltalk Books (Blue Book)

Design Principles Behind Smalltalk

Advanced object-oriented design and development with Pharo — Course — FUN MOOC (fun-mooc.fr)

Meta-environment and executable meta-language using Smalltalk: an experience report