Pharo: Reinventing Smalltalk

Stéphane Ducasse is the Research Director at INRIA Lille leading the RMoD team into R&D for Pharo, the Smalltalk-inspired open source programming language. He is also the President of ESUG (European Smalltalk User Group). Stéphane is perhaps the most public face of Pharo, having produced many leading-edge advancements in the language, and given many talks and seminars about them.

Recently, I had the honour and pleasure of interviewing him for this article. I hope you enjoy his wonderful insights and vision for the future of Pharo.

Richard: Good morning, Stéphane. It’s a pleasure meeting you. As a leader for the development of Pharo, what do you see as the chief goals for the language?

Stéphane: This is a vast question! Let me try to answer in an organised manner and we can go deeper into them if you want later on.

First, we want to create an engine so that we can reinvent itself. Yes, this is a bit circular but the idea is to have a system that can evolve for the next 20 years. This has several consequences: infrastructure should be super robust and flexible, the system should be moldable to future needs, it should be reflective.

Second, we want an environment (community, teachers, entrepreneurs) where innovation and business bloom. For us, this is important — Pharo is not a prototype, it is a real platform. This is why we created the Pharo Consortium. This way, companies put money on the table to sustain Pharo development and their business.

Third, we want a system with new generation tools: tools that change the way to think and tackle your problems. We are working on new generation debuggers, browsers,…

Fourth, I want a system that empowers its users by being a place to learn.

Now Pharo is what we have today and not necessarily what we dream about. I’m used to saying that Pharo is a bus that we are all using and that we start from north of Europe heading south and by the time we arrive in the south
it should be a super new generation aircraft and not a bus.

Right now, we debug remotely live IoT devices; we code in the debugger; we can generate runtimes that are around 100-200K (we went down to 11K in fact). The tools such as GTInspector and the debugger are getting really good but I want more. :)

We know the places that we want to improve and we can discuss them.

Richard: What are the areas where Pharo has made progress?

Stéphane: Over the years, Pharo really improved in many areas, most of them related to infrastructure.

For example, the file system was rewritten from scratch based on the work of Colin Putney for Squeak. A new compiler, Opal, emerged. It supports Reflectivity, a new really powerful reflective layer actively developed by Marcus Denker. Opal needs another pass but it has been in production for several years already.

On the server side, Zinc, a new HTTP/HTTPS client server, was developed and it is actively maintained by Sven van Caekenberghe who uses Pharo on the server side in his company. Now what is really nice is also all the packages coming around Zinc, such a Teapot (you can write a HTTP server in a page of code), but also all the JSON, CVS and other conversion packages. They are all excellent and with nice documentation.

At the level of the tools, Pharo got a new set of powerful tools developed by the GT team. The inspector is simple gorgeous. The debugger got completely rewritten.

The Virtual Machine drastically evolved with the superb work of E. Miranda from Stelec and C. Béra from our team (and some other guys helping for some parts such as the JIT for ARM by Tim Rowledge). We will release soon an optimising JIT and we will get around 30% more speed. What is fascinating is that a team of two guys could deliver an enormous piece of engineering and compete with the team at Oracle and Google. Of course, Pharo will be still slower than Java or JS but let us compare the engineering time. It is amazing that the world is totally blind at this level.

In Pharo, we did not get millions of euros spent on the VM but we will be one of the four or five languages in the world with an optimising JIT. This is a bit sad that the world does not count the ratio of energy spent and result. So we can really feel proud of our results and the productivity of the approach.

For Pharo 70, the integration with Git is also radically changing our presence on GitHub and we are designing a new process for Pharo and its ecosystem.

A change that the end programmer does not really see but that we (the core dev team) are super proud to have: Pharo 70 is bootstrapped from source.
This is the result of three years of efforts and the PhD of G. Polito. Guille showed that he can produce kernels around 200k (he even did a kernel only printing two small ints in 11k!). Now people may wonder why we are so excited about this:

• first, a bootstrap is a process to make sure that we know how to initialize core aspects, it also helps building the notion of time zero. We have the warranty that we can identify such state.
• second, it means that we can modify some core features off-line and not reflectively: without having to consider that we are doing brain surgery on ourselves.
• finally, what we will get in the future is minimal core and many Pharo assembled distributions. People will build their own: one for the web, one for IoT, etc.

The full ecosystem also improves with many libraries, bindings, I cannot follow in fact. Of course, you do not get 5 different libraries like in JS but you often get a well-designed and working one.

For Pharoers, the infrastructure is a central aspect because it should enable all the rest. A good flexible architecture should enable people to invent a new approach to their problem. In addition, what you can see as a red line in my description is that Pharo is a really community effort and this is really a great feeling. In fact our objective is not to be the guys doing Pharo. We just do it because this is important but if people really wants to get involved, they are really welcomed.

Richard: What are the tools that you envision?

Stéphane: I would love to bring live programming to the scripting area. Here is the scenario I would love (when I’m fed up to debug bash): you run your script and you get a bug, you run your script in debug mode and you get a super cool Pharo interactive debugger, you walk the stack, change the code and find your bug. You close the debugger and you can run your fixed script. Voilà!

On a much simpler ground, I envision architectural validation of projects (we have a tool to check the dependencies so it should just be enhanced).

The fact that we will have a tool-based process to manage modular Pharo itself, we will have more powerful tools including graphical representation, for example, using scripting visualisation language such Pharo. This is what the Moose platform is doing and I would like to see this happening for Pharo but in a modular fashion. I do not want to have Roassal loaded by default.

Finally, now what strikes me is that we are constantly fighting with DSL without tooling: I was editing YAML Travis files and Bintray for Pharo books and this is boring to debug. The vision I have for Pharo (and we are getting there) is that you should be able to build tools to handle all the “easy” little and boring time consuming tasks. With the moldable idea promoted by the GT team I see this happening.

And this will radically change the way we solve problems.

Richard: What are the areas where you see that Pharo should progress?

Stéphane: We massively cleaned the code and there is still progress to be done. Fonts, shortcuts, streams. There are several areas where we will see results and/or I would love to see new solutions:

• Integration with the OS. Pharo should be used as Ruby for scripting and the OS integration should be much better than now.
• We need a better application deployment: right now coding in Pharo is cool and powerful but there is no button to say “Please package this code as an app and deploy it” and I want that. This is has nothing with the language. Dolphin Smalltalk could package an app in a DLL. So we can do it.
• We have new stream packages and we should use them instead of using rather old one.
• There is a huge amount of work that will arrive soon at maturity: the complete redesign of the core graphics and the widgets. It will change the face of Pharo and it will be gorgeous. Now we should make sure that we continue to apply our “Favor constant delivery over no perfect solution” motto.

Richard: Can you tell us more about Pharo being a place for learning?

Stéphane: What I mean is that I want each method of the core system to be documented with one example that I can execute live. Often a pro developer knows things and does not think anymore that a class or method would deserve a simple but super welcoming comment and example.

I hate all the manpages that describe to me at length the possibilities but never give one simple example. Because with this simple example, then I could do my job much faster and I would be empowered.

This is why any Pharo programmer can take ten minutes and add a nice comment with an example à la Python’s doctest.

We have the support and we can execute the example live. So let us do it.

Richard: Thank you very much. Do you have any final closing remarks?

Stéphane: Near the end of each Pharo release, I feel that we make really nice progress and as soon as we start a new cycle, the new work performed by the community is exciting.

So Pharo is really exciting. The community is regularly growing and new libraries are popping up.

The future will be really interesting and I love to be part of such a great and energizing system and ecosystem.

(This interview article is a sequel to “Behold Pharo: The Modern Smalltalk.”)