The Pharo Smalltalk ecosystem
This blog post was written a long time ago and may not reflect my current opinion or might be technically out of date. Read with a grain of salt.
Written on December 6, 2011.
This post is intented to developers who’ve heard that Smalltalk is hot and sexy. A fraction of them have tried to download a One-Click version of Pharo and played a bit with the language by following a tutorial or two.
So now they have a taste of Smalltalk but they do not get the entire picture, how the environment work, how people actually build and deploy software with it. If you are one of them, you’ll probably want to take some time to read this :)
Images and VMs
If you’ve downloaded a One-Click image, you haven’t experimented with the notion of image and VM in Smalltalk. Actually you have but not in an explicit way, you’ve simply clicked on an icon and got your environment. You’ve maybe ‘Quit and Save’ and when reopening the application you had the same state than when you left. Easy.
In pratice, Pharo works with an image running on top of a virtual machine. If you come from another scripting language, it certainly offers a REPL (e.g., IRB for Ruby). Think of the image as a dump of that REPL at a given moment.
A Pharo image contains everything: your code, the tools and the libraries. You can load code into it, you can save it and restart it at any moment. This image is closed. That’s why you cannot use your text editor to edit Pharo code (actually you could but you certainly would not want that).
The VM is usually something you should not care about. My advice is to use the one given by the Pharo website, it is tested by a Jenkins server and is the one people use the most.
In a nutshell: download a VM and an image from the official website. At this moment, the stable version is Pharo 1.3 and the image is CogVM-13307. I personnaly put the VM in the
/Applications folder on my Mac. The image comes with a
.sources files. Keep them in the same directory than your image.
Beware that the evolutions of the image and the VM are not tight. It is possible that a Pharo 1.3 image will run on a new VM version in two years.
To start an image, double-click on it. If your OS does not get it, you can drag the image icon on the VM icon. That should work.
When you download the image, you can see the exact version you are downloading:
Pharo-1.3-13315.zip. It means that it is the 315th revision of Pharo 1.3. The 13xxx part is redundant with the Pharo-1.3.
The VM has currently the name
CogVM-Mac-13307.zip. Which means it was frozen with the 307th revision of the Pharo image.
Source version control
Your code is in the image. You don’t even have a full text view of your nice classes. How do you persist it? So far, you’ve probably save your image and re-open it later. That’s the best way to lose everything if your image crashes (and that happens). It’s also not really handy if you’re not alone on the project.
Monticello comes to the rescue. It is a version control system like Git, Subversion or Mercurial. The only difference is that it does not version files but classes and methods. That’s pretty great for an object-oriented language, isn’t it?
Historically, Squeaksource is the GitHub of Smalltalk. It is old, ugly and slow but it works. A more modern alternative is SqueakSource3, which brings Squeaksource to the latest frameworks. There are less projects than in the original Squeaksource but you should use it for your new projects.
SmalltalkHub is on its way. It is not stable enough to be used in production but we are all waiting for it :)
James Robertson has made two (very short screencasts to help you get up and running. You won’t need more than 4 minutes to watch them.
- Smalltalk For You, episode 48, you’ll see how to save a package in a Monticello repository. Gives you all the basic information you need to know to use Monticello. Three minutes. That’s it.
- Smalltalk For You, episode 49, this screencast will show you how reload the code you saved in the previous screencast in a fresh image. A little more than one minute.
Load external libraries
Loading code in your image is pretty easy. Open a Monticello Browser and add the repository from which you want to load code. Et voilà, done.
The problem is that sometimes, a package has dependencies. So you end up losing 4 hours only to track the dependencies of the package and to figure out a load order. Metacello was designed to help you.
A project can provide a “Metacello Configuration”. This configuration describes the dependencies and the load order of the project. Of course a configuration can load an other one. You can also tag versions of your project.
When you want to use a project, the first thing to do is to find its MetacelloConfiguration. As of today, the lookup to find a configuration is:
- Check if the project exists in http://www.squeaksource.com/MetacelloRepository.html. This repo is a goldmine.
- If it is not there, check in the project repository if you find a
- Ask the Pharo-users mailing list.
If your project is not trivial, you should write a ConfigurationOfYourProject. You can get inspiration from other configurations. I personnaly like the ConfigurationOfFuel.
Once again, James Robertson has already covered the subject in his Smalltalk For You screencast series. Episode 82 shows you how to load GlorpDBX (an object-relational mapping package for Smalltalk) in a fresh image using Metacello Configuration in a little more than two minutes.
Ok, so now you know the tools that are used by Pharo developers. Let’s move on to the next critical point: Good habits.
New image everyday
As you save your image and reopen it 16 hours later in exactly the same state, you are probably tempted to keep it forever and do all your development in it. So convenient.
In theory only. With time, you experiment and create a bunch of stuff you won’t need. You have loaded many external packages and you don’t know anymore which are your dependencies. Your image becomes bloated, it may eventually crash.
The best way to avoid rotten images is to get a new one everyday. Download a stock Pharo image (or keep one somewhere locally) and load your MetacelloConfiguration. This will have two benefits:
- Your image is always clean and not bloated.
- You know that your code load and works. This way you are sure that your co-workers can load your code and deployment is smooth.
Keep your images organized
I’m sure you’ve already think about it but try to keep your different images organized. it is not hard to end up with dozens of Pharo images scattered across your hard drive. Try to keep things simple. For example, I keep a directory with all my stock images (Pharo 1.2, 1.3, the preversion of 1.4, Squeak, One-Clicks, etc).
Choose a convention and stick to it.
Syntax conventions & micro decisions
Follow the conventions used by many Smalltalkers. Naming conventions as well as indentation. A very good read is Smalltalk Best Practices Patterns by Kent Beck. Follow this style your code will follow Smalltalk idioms. Actually, the patterns discussed are also valid for Ruby. So go and grab your copy.
I wanted to write this guide for a long time now. This article for Python convinced me to post it.
I hope it will be useful for some folks who want to try Smalltalk (and its Pharo implementation). Feel free to email me or to comment if you have any question or suggestion. If you are a Ruby developer wanting to learn Smalltalk, please drop me an email, I need your help for future posts !