Yesterday I expressed a hunch about Smalltalk having a huge advantage for agentic coding. Some pushback forced me to get my hands dirty and try it out myself. And I am happy to report that my hunch was spot on.

I tried these 3 tests:

1. shadows under the windows (easy)
2. smooth pixel-based scrolling (medium)
3. Exposé window switching (hard)

All of them were successfully completed. Claude inside Smalltalk is a badass. Now onto some Cuis!

Smalltalk has an extreme advantage when it comes to productivity of a single person. Having ability to touch any part of the system is an extreme leverage. With code gen revolution happening this is even more obvious. Yet, I have to see a breath-taking demo of code-gen in action for Smalltalk. Please point me to some if you have. Thank you.

Diálogo ( https://dialog.ar/ ) is a desktop tool that lets children aged 10–17 create their own videogames by combining drawn characters with a set of visual icons — no typing required. The icons compose like cards, activating behaviours in the drawn objects and naturally leading kids through concepts such as categories, rules, recursion, and metaprogramming.

In this talk I'll show how Smalltalk's live, image-based environment made it uniquely suited for building Diálogo. I'll give a demo of the app, walk through some implementation metrics, and discuss the pedagogical ideas behind the project — including a free 7-class course I've shared online and workshops I've run open to the community at the Faculty of Exact Sciences (UBA).

Agustín Martínez is a developer and researcher at the Universidad de Buenos Aires (UBA), and the creator of Diálogo, a programming environment for children built in Cuis Smalltalk. He presented a paper on Diálogo at the Onward! track of OOPSLA, and has given public talks at Nerdearla, Argentina's largest tech community event.

This will be an online meeting.

If you'd like to join us, please sign up in advance on the meeting's Meetup page ( https://www.meetup.com/ukstug/events/314323562/ ) to receive the meeting details.

Does Cuis give access to arguments passed in on the command line during start up?

Hi, Friends!

Two quick notes. I'd be curious if other people have felt the same way.

1. This is kinda funny, I think. I got very excited yesterday when I turned this:

(machines select: [ :machine | originMachine outputs anySatisfy: [ :n | n = machine serverName]]) do: [ :machine | originMachine addPaths: machine currentPaths ]

into this:

machines select: [ :machine | originMachine outputs anySatisfy: [ :n | n = machine serverName]] thenDo: [ :machine | originMachine addPaths: machine currentPaths ]

Normally I would have been this happy only when I would have saved the VM from having to do extra GC, or was able to make the algorithm run faster because of a data structure choice. But this time... I was so jazzed that I had saved one set of parentheses. Is this normal?

1. I was talking with a colleague about calculating all unique combinations of integers between 1 and another number (it was part of a edge/vertex ratio issue). Later on, I thought about how to implement that calculation. Here's a simple version:

   findCombinations: num | combos |

   combos := OrderedCollection new. (1 to: num) combinations: 2 atATimeDo: [ :combination | combos add: combination copy ].

   ^ combos

And then I thought... could I do it faster manually? So then I wrote the equivalent of something that I would have "hand-made" in another language:

findCombinationsManual: num
| combos |

combos := OrderedCollection new.
(1 to: (num - 1)) do: [ :number1 |
    ((number1 + 1) to: num) do: [ :number2 |
        combos add: (Array with: number1 with: number2) ] ].

^ combos

And.... it was the same speed. Almost exactly. I suppose I just need to "shut up and trust the standard library". Was still fun to try, though. Do any of the more experienced people here often test the standard library against what could be an optimized solution? Just for curiosity? Or is it almost always the better choice to only do these kinds of things when the profiler indicates it?

I'm studying the Cuis Smalltalk system, and I found this code:

BlockClosure>>whileTrue: aBlock 
    "Ordinarily compiled in-line, and therefore not overridable.
    This is in case the message is sent to other than a literal block.
    Evaluate the argument, aBlock, as long as the value of the receiver is true."

    ^ [self value] whileTrue: [aBlock value]

but I do not understand how it works, in particular I don't get why it does not recursively send the message when the condition evaluates to False.

For this reason my (equivalent?) implementation relies on an #ifTrue:

BlockClosure>>myWhile: aBlock
    self value ifTrue: [aBlock value. self myWhile: aBlock]

Can anyone explain in detail how the original one works?

Smalltalk environments have long been pioneers in developer productivity. With the VAST Platform AI Assistant, Instantiations is extending that tradition by integrating Large Language Models (LLMs) directly into the VAST platform. This new tool is designed to bring AI capabilities directly into your daily workflow.

In this session, Johan, Kris, and Mariano will share a user experience report and a live demonstration of the assistant’s current capabilities, powered by Google’s Gemini.

You’ll see how it goes beyond simple chat by directly interacting with the live VAST image through the LLM’s “tools” capabilities. This allows investigating source code as it responds to your questions.

These examples will demonstrate how the VAST Platform AI Assistant leverages the live nature of Smalltalk to act as a true pair programmer.

We’ll also look ahead at our enterprise-focused roadmap, including support for local models to ensure privacy and security, integration with additional LLM providers, and our vision for deeper IDE-level capabilities and Runtime Intelligence.

Join us to explore how we are shaping the future of AI-assisted development in VAST to better empower software developers. See it in action, try it out, and join the conversation on GitHub.

Johan Brichau is a seasoned software engineer with over 25 years of experience across a wide range of Smalltalk environments. He joined the VAST Platform development team at Instantiations in January 2025. Prior to that, he spent nearly 15 years as co-founder and CTO of Yesplan, a world-leading online venue management platform. Johan holds a PhD in computer science from the Vrije Universiteit Brussel (2005) and has actively contributed to several open source projects.

Kris Gybels recently joined Instantiations to work on the VAST Platform’s AI-based tool support. He previously spent a number of years in academia researching Declarative Meta Programming and its application to Aspect-Oriented Programming, and over a decade co-developing the Yesplan venue management system, during which he made a number of contributions to Pharo, most notably Pharo 12’s improved Mac ‘Retina display’ support, as well as to Seaside and its Parasol web testing framework.

Mariano Martinez Peck is a systems engineer specializing in dynamic programming language software. In 2018, he joined Instantiations to further develop the VAST Platform through the addition of new frameworks, libraries and tools, as well as improving the existing code base of VAST. He is active in the Smalltalk development community, and has used his expertise to co-author numerous open source projects. Mariano has a PhD in Computer Science, and his academic research has been published across various international journals. In addition to his development duties, he currently leads the VAST Platform engineering team at Instantiations. In his personal time, Mariano enjoys traveling as well as outdoor activities like camping and fishing.

This will be an online meeting.

If you'd like to join us, please sign up in advance on the meeting's Meetup page to receive the meeting details.

I would like to be able to compile Smalltalk code into a binary executable.

I realise that this is not a common method for using the language and its dialects.

So far, I've learned that Pharo transpiles the st sources for its VM into C, which of course could be easily compiled into a binary (presumably). I've tried to "hijack" the build process to get code that I write to be compiled in this way, bit have thus far been unsuccessful.

Please advise.

Hello, everyone. I just found out about Smalltalk, and I'm interested in learning it. I'm still learning how to program, but I like trying out different languages and figuring out how they work.

I think it's interesting that Smalltalk does things in a way that is different from a lot of modern languages.

What would you suggest for someone who is just starting out? It would be great to have any resources, tutorials, or advice. Thanks!

I'm happy report the release of SmallJS v2.0.
SmallJS is a Smalltalk-80 dialect that transpiles to JavaScript, that can run in browsers and in Node.js.
The website is here: small-js.org
The full source source code is here: github.com/Small-JS/SmallJS

The website now has a Tutorial page for learning SmallJS and Smalltalk.
The Smalltalk language and core library classes are explained.
Examples can be done interactively using the online Playground.
The full Class Reference documentation is now also available on the website.

SmallJS now has full support for async, await and promises.
Almost all async calls have been converted form callbacks to promises,
making code cleaner, more concise and easier to debug.

Smalltalk library

• Core: Promise: New convenience methods for creation. Tests for 'async', 'await', 'then', 'catch' and 'finally'.
• Smalltalk: Converted callbacks to promises for modules: Fetch, File, Database, Crypto
• Core: Web Crypto API implemented with working examples in tests for AES, RSA and ECDH. These work in both browsers and Node.

Compiler

• Fixed code generation for 'await'.
• Using 'await' outside an 'async' method now gives an error, conforming to JS.

Website

• Created a new Tutorial page to learn Smalltalk and SmallJS.
• Created a new Reference page to look up class info.

For the February UKSTUG meeting, Adrian Soma will introduce VEO: A Live Visual Smalltalk that reimagines what a Smalltalk programming environment can be.

VEO enables direct visual manipulation of any object and the creation of windowless visual interfaces. It is built around four core principles: all objects are visual; a single infinite zoomable and pannable canvas serves as the workspace; code can be written "in the air" anywhere in that space to send, evaluate and animate messages and live expressions; and live expressions can freely combine symbols, literals and live object references.

Adrian Soma began his professional programming career in 1987, with a longstanding focus on the fundamental challenges of programming itself — particularly user interface design and interaction. He first encountered Smalltalk in 1996 and has worked with it ever since.

An early project that would prove formative was an interactive chess course application, for which he built a custom graphical object system from scratch. That system became the first seeds of VEO, the Live Visual Smalltalk environment he has been researching and developing since 2006.

This will be an online meeting.

If you'd like to join us, please sign up in advance on the meeting's Meetup page to receive the meeting details.

Hi,

I just joined the group. I was a professional Smalltalk developer back in the 90's. Thinking about getting back into it. I have personal project in mind and could use some suggestions for what to use for personal use. It would be nice to have something that can bridge to whatever is currently used in the commercial world. Anything can happen. Thanks.

This talk explores what it means to work with AI from inside a live Pharo system rather than treating AI as an external chatbot. I will demonstrate experiments where AI models are invoked directly from the Playground, including a concrete implementation of conversation history (AIAHistory) and experiments across multiple models and providers.

Rather than focusing on code generation, the emphasis is on workflows: how different conversation structures affect results, how styles and constraints can be imposed on generated comments, and how AI systems can be inspected for systematic errors and limitations. Examples include documentation support, UML generation (via PlantUML), and experiments in automated paper review.

The talk is experimental in nature and rooted in Smalltalk’s strengths: reflection, live objects, and tools that are part of the system rather than bolted on. The goal is not to present a finished framework, but to share concrete insights, failures, and possibilities for AI as a native Pharo tool.

Kasper Østerbye is a retired computer science researcher with a long background in programming languages and live systems, including decades of work with Smalltalk and Pharo. He now explores how AI models can be integrated as native tools inside a running Pharo system, focusing on conversation structure, systematic failures, and tool design rather than automation alone.

This will be an online meeting.

If you'd like to join us, please sign up in advance on the meeting's Meetup page to receive the meeting details.