Objective-Smalltalk can be confusing because it’s not a single monolithic entity but rather a series of interconnected stages, each building upon the previous one. While it’s common to focus on individual aspects, understanding the entire progression reveals a more complete and valuable picture.

1. WebScript 2 / “Shasta”

Objective-C has always excelled at integrating with other languages, especially scripting languages like Python, Ruby, and Lisp. This is largely due to its dynamic runtime and its close relationship with C.

However, these integrations often involve managing two separate languages with different object models and runtimes. WebObjects’ WebScript, essentially Objective-C-Script, offered a solution by providing a tightly integrated scripting environment. It was so closely aligned with Objective-C that code could often be copied and pasted between them.

Despite its advantages, WebScript inherited some of Objective-C’s syntactic quirks, which were necessary for its integration with C but became unnecessary and awkward in a pure scripting context. The first stage of Objective-Smalltalk aimed to retain WebScript’s strengths while shedding these inconsistencies. This resulted in a language that closely resembled Smalltalk, aligning with the concept of Shasta.

This approach enables a more interactive programming experience:

[Placeholder for image demonstrating interactive programming]

This interactivity extends beyond isolated code snippets to encompass the modification and exploration of complete applications during runtime:

[Placeholder for image demonstrating application interaction at runtime]

2. Objective-C without the C

While eliminating Objective-C’s syntactic quirks in the scripting language made it cleaner, it also sacrificed direct syntactic compatibility with Objective-C. This was unfortunate because the seamless code exchange between WebScript and Objective-C was highly valuable.

The natural solution was to create a native, ahead-of-time (AOT) compiled version of this scripting language, effectively replacing Objective-C. Unlike many scripting languages that struggle to achieve efficient compilation, this approach benefits from the semantic model of the scripting language being very close to Objective-C. This allows for a relatively straightforward AOT compiler that integrates well with the existing tools.

While this combination of a simplified language, integrated scripting, and instant builds presents a compelling alternative to Objective-C, it raises the question of whether another object-oriented language is truly necessary, especially considering the limited success of projects like Etoilé project and eero language.

3. Beyond just Objects: Architecture Oriented Programming

Since authoring “Approaches to Composition and Refinement in Object-Oriented Design” in 1997, there’s been a strong interest in software architecture and Architecture Description Languages (ADLs) to address the complexities of large-scale software development.

Early on, it became clear that ADL elements closely correspond to programming language elements, particularly in object-oriented languages. This suggests that programming languages are essentially specialized instances of a broader “architecture language.”

To investigate this connection, a malleable and compact language suitable for experimentation was needed. A simple variant of Smalltalk fit these criteria well, as opposed to more mature variants that can hinder experimentation (Alan Kay).

Objective-Smalltalk, built upon Objective-C (itself bridging C/Unix and Smalltalk), proved ideal for exploring architecture-oriented programming.

This exploration focused on integrating three prominent architectural styles:

• Object-Oriented Programming (encompassing other call/return styles)
• Unix Pipes and Filters
• REST

These styles surprisingly aligned well with existing programming language elements. Object-orientation was already inherent in (Objective-)Smalltalk, dataflow mapped to a generalized assignment operator, and REST found a partial mapping through non-message identifiers.

Integrating these abstractions into Objective-Smalltalk yielded unexpectedly positive results. While acknowledging potential confirmation bias, the convergence of these ideas suggests a deeper underlying principle.

4. Architecture Oriented Metaprogramming

While the architectural styles are currently implemented as frameworks with interfaces hardcoded into the language, three examples presents an opportunity to define these styles directly within the language. This would empower users to define and refine their own architectural styles, representing an exciting area of ongoing work.

What now?

Each stage of this progression holds value as a standalone project. They become even more compelling when combined, highlighting the interconnected nature of this work.

A key priority is resuming work on stage 2, which wasn’t strictly required for the initial exploration of stage 3.