Pharo development
Written on October 10 2011.
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.
I sometimes wonder why Pharo has such difficulties to get a stable version. Even when a release comes out, it is not that rock solid.
When building an image, you get code from various locations. Integrating everything together seems hard. For example, a package will use a syntax highlighting mechanism, which will be different that the one used in another package. Different shape, different quality, different patterns, it is hard to get the same foundation for everything when you cover many areas: gui, drawing, threads, locks, filesystem, etc.
Smalltalk acts as a whole operating system, it is one of its strength but also one of its weakness. It sounds wrong when you are used to the Unix philosophy where one tools equals one function. Smalltalk breaks that and want to do everything by itself. It becomes nice when you want to do something that crosses different layers (delayed_job would be almost useless in Smalltalk); you start your image and everything runs inside it. You stop it, everything stops. Easy. The drawback is obvious: Smalltalk environments tend to reinvent the wheel all the time.
When you consider this, you start to realize the tremendous amount of work done by the developers. They proceed by baby steps but they are going very far… And I can’t wait to use Pharo for system scripting