Pulsar: Use It. Break It. Improve It.
Pulsar is a new coding-first IDE for Pharo, designed around real working sessions and built to help programmers become power users. Now in pre-alpha after winning first prize at ESUG 2026, it needs people willing to use it, break it, and help shape what it becomes.
Introducing a coding-first IDE for Pharo.
In July 2026, at ESUG 2026 in Plovdiv, I presented Pulsar, a new coding-first IDE for Pharo. The talk was meant as a first public unveiling: a way to show the direction, explain the problems I am trying to solve, and invite people to try it.
To my great joy—and surprise—Pulsar won first prize in the ESUG Innovation Awards. This makes it a good moment to write down what Pulsar is, why I am building it, and what kind of help I am looking for.
Pulsar is not “another four-pane browser.” It is an attempt to rethink the Pharo development experience around a simple idea:
An IDE should help the programmer become a power user.
Not by forcing people to memorize obscure shortcuts. Not by hiding power behind magic. Not by replacing programming with a new metaphor.
By making powerful ways of working easier to discover, easier to repeat, and easier to keep in context.
Coding first
That may sound obvious, but it matters. Code is where most of our work begins and ends. We read code, follow code, change code, test code, debug code, and eventually commit code.
So the central activity of Pulsar is built around the coding loop:
explore → code → verify → commit
The goal is not to make the IDE disappear. The goal is to make it support the work without constantly stealing the scene.
Preserving what is good
Pharo already has a lot of excellent tools. The traditional Smalltalk browser is still a very strong metaphor. It gives us a compact and powerful way to navigate methods, classes, protocols, packages, and the surrounding system.
Pulsar does not start from the idea that everything we have is wrong.
Quite the opposite: it starts from the idea that there is a lot worth preserving.
But it also starts from a practical frustration: the work we do today often does not fit inside a single browser frame.
A real session moves between code, tests, senders, implementors, objects, histories, playgrounds, repositories, files, and sometimes external tools. Programming is not a straight corridor. It is a graph of questions.
Pulsar tries to hold that scene.
Hold the scene, not just the frame
One of the design ideas behind Pulsar is that the IDE should help you keep the broader working context visible.
When I am working on a method, the method is the focus. But the method is rarely alone. There are tests that protect it, objects that explain it, senders that depend on it, experiments around it, and changes waiting to be committed.
The current browser frame is important.
But the scene around the frame is what lets me stay oriented.
Pulsar tries to make that scene easier to navigate without turning every question into a permanent window, tab, or piece of clutter.
Explore freely, keep deliberately
You look for a sender. You inspect an object. You open a test. You check an implementation. You try a small experiment. Most of those moves are temporary.
Current IDEs often make temporary exploration feel too heavy. You open tool after tool, accumulate windows, lose the path, and then spend time cleaning up the consequences of your own investigation.
Pulsar tries to make exploration cheap:
easy to start, easy to follow, easy to discard.
Temporary things should stay temporary by default. But when an exploration becomes important, you should be able to keep it, dock it, or detach it into its own place.
Temporary by default. Persistent when it earns its place.
Start from your project
Another important design decision is that Pulsar starts from the project.
The whole image is not a useful starting point.
A modern Pharo image can contain thousands of classes, hundreds of packages, many repositories, and years of accumulated work. Having access to everything is powerful, but being exposed to everything all the time is not the same as being productive.
Pulsar uses the project as the first scope of work.
That includes persistent projects—currently represented in Pharo through baselines—but also lighter-weight “volatile” projects: places where you can start working without first having to define the perfect baseline. Sometimes you need a sandbox to give form to your future project.
The IDE should support both.
Integrated with the system
Smalltalk has a long tradition of being a full machine. That is one of its great strengths.
But today, it does not live alone.
Our projects are not only inside the image. They live in repositories, files, terminals, documentation, external tools, services, and operating-system workflows.
So Pulsar reinterprets “integrated environment” in two directions:
- integrated across its own tools;
- integrated with the desktop and the surrounding system.
That means the IDE should compose with Git, files, repositories, terminals, and external resources instead of pretending they do not exist.
Pharo should remain Pharo. But the operating system is real too.
Familiar, but not generic
Most people who come to Pharo arrive from other programming environments.
Pharo and Smalltalk are already different enough. The IDE does not need to be alien just for the sake of being alien.
Familiarity is not cosmetic. Familiarity saves attention.
If something can look and behave in a way that people already understand, that gives them more energy to learn what is actually different and powerful in Pharo.
Pulsar tries to be familiar enough to enter, and Pharo enough to belong.
What you can try today
The alpha already lets you experience the main shape of Pulsar: start from a project, browse and edit code, move through related tools without losing your place, and keep the useful parts of an exploration in view.
It does not yet cover every workflow, and its different parts have not all reached the same level of maturity. That is precisely why trying it now matters: feedback can still change not only the details, but the shape of the environment.
The current status
Pulsar is currently in alpha.
It is not finished, and I do not want to pretend otherwise. But it is already useful. Some parts remain experimental or incomplete, while others are still design pressures looking for the right implementation.
But the direction is clear:
- coding-first;
- context-preserving;
- progressively powerful;
- project-scoped;
- desktop-aware.
In summary: designed for real working sessions.
The ESUG Innovation Award is encouraging, but the real test starts now: whether Pulsar can become something people actually want to open, use, and improve.
Use it. Break it. Improve it.
I want Pulsar to become an IDE people actually want to use.
That means I need feedback from people who write Pharo code every day. I need people to try it, complain about it, break it, suggest workflows, find missing pieces, and help shape what it should become.
The question I care about is not only:
“Do you like it?”
The real question is:
What would Pulsar need to do for you to think, “I want to use this”?
If you are comfortable trying early-alpha software, I would love you to use Pulsar in real working sessions and tell me where it succeeds—and where it gets in your way.
You can try Pulsar and find installation instructions here: https://forge.smallworks.eu/pharo/pulsar.
Use it. Break it. Improve it.
And help bring out the power user in all of us.