Pharo

the Immersive Programming Experience

Why do we choose to use Pharo? We feel that Pharo provides the best way to combat complexity in software development.

As long as the number of software developers paid to make software smaller and throw away code is a lot smaller than the number of developers paid to add code, the software we need to deal with on a daily basis will continue to grow. This inevitably leads to an increase in the complexity of the systems we build. This complexity is problematic because decision making in difficult situations is biased (1), using first fit heuristics instead of best fit.

An interesting observation (2) is that successful software tends to have technical debt. If a software system is successful, the market pressure to deliver more and faster than technically advisable is difficult to resist. When growing very fast, it can make sense to make choices that enable short-term growth that will need refactoring later. Additionally, an architecture that is optimal for a small system is not ideal for a large system and vice-versa.

So, what can we do? There are several interesting models describing how to deal with complex software systems. Let’s check a few of them, and see what Pharo has to offer there.

The Cynefin framework (3) categorizes the problem space into 5 domains:
- Obvious, where the relationship between cause and effect is obvious to all;
- Complicated, where the relationship between cause and effect requires analysis and/or the application of expert knowledge;
- Complex, where the relationship between cause and effect can only be perceived in retrospect;
- Chaotic, where there is no relationship between cause and effect
- Disorder, where the type of causality is unknown.
Each domain needs a different approach. In the complex domain the approach is Probe, Sense, Response, or run multiple safe-to-fail experiments simultaneously and see how the system responds.

Pharo is well-suited to doing experiments and prototyping.

It offers fast feedback with instantaneous compilation of the currently edited method, optionally running an auto-test on the changed code.

The system contains all the source code of all the tools, and they are designed to be quickly customizable by the individual developer. A stated goal is to be able to build a custom tool in 10 minutes.

Pharo immerses you in a sea of objects and provides you with lots of different ways of looking at them. The late binding allows manipulating these objects at run-time, even modifying the run-time stack.

Real Options (4) provides a decision model based on
- Options have Value
- Options Expire
- Never commit early unless you know why

Pharo embraces this model. Code is compiled as late as possible, in the running system. This makes it possible to use information available only then to customize behavior

Behavior is triggered only by message passing, and the receiving object decides what to do with a message. Sending an object a message it does not understands is caught at run-time and can be dealt with in several ways. It makes it easy to create proxies and can be used to teach objects new behavior.

Debugger-Driven-Design is an approach unique to smalltalk systems. It makes it possible to design the way objects communicate while implementing it. It supports a superior way of doing test driven development.

Small is Beautiful (5) is something that is very much applicable to software. Software systems suffer from dis-economies of scale.

Pharo uses a very simple and orthogonal language, using a very small set of constructs. But this very small set of constructs contains all the needed features for building highly complex, understandable and reusable software architectures. This reduces the cost of building custom tools and makes it possible to cost-effectively provide such an advanced environment. The systematic refactoring applied over many years pays off in a very “dense” library that makes it possible to solve problems writing a very low
number of lines of code.

The state of the art in mainstream software development to battle complexity is reuse at the application level, building systems out of large-grained components (database, web server).

Pharo supports reuse at a much lower granularity. It has lots of small domain specific languages to deal with specific problems. Because smalltalk has so little syntax and supports fluent interfaces, these languages
support describing problems and their solutions in a language near to that of the domain expert.

All software development environments support programming yourself into a corner. Making decisions that turn out to be bad is inevitable when building complex systems. Being able to program yourself out of that corner again makes it possible to approach a problem without fear.

Pharo offers easy meta programming and a code rewriting engine to help undoing bad design decisions and cleaning up large amounts of code in a controlled way.

The choices made by the Pharo project put it on the left hand side on the value chain map (6). Suitable for innovation, focusing on effectiveness instead of efficiency.

Pharo is an open source project, supported by the Pharo Consortium. It is both a research vehicle and a platform for commercial software. We use continuous integration to make sure that the innovations from research don’t destabilize commercial developments. Our new state-of-the-art “Spur” vm was released recently, providing much faster execution and an excellent growth path for optimizations.

(1) Gary Klein (1999) Sources of Power: How People Make Decisions.

(2) @meekrosoft, Mike Long (Long Life Software), 2013,
Cleaning Code — Tools and Techniques for legacy restoration projects

(3) Dave Snowden
http://cognitive-edge.com/

(4) Chris Matts and Olav Maassen, Committment, the Book.
Expands on the ideas articulated by Kent Beck in
“Extreme Programming Explained, Embrace Change”
http://commitment-thebook.com/

(5) E.F. Schumacher, (1973) Small is beautiful: A Study of Economics
As if People Mattered.

(6) Simon Wardley, http://blog.gardeviance.org/