Monticello Metacello

Squeak and Pharo saw a great config change in 2010.

The issue is how to incrementally construct a  bytecode "image" for a Smalltak VM, but it is the Smalltalk equivalent of make and configure for a build.

Building up Smalltalk images has been a nasty secret in the the otherwise sunny world of design, test and develop in Smalltalk.  The darkest secret - which managers learn about eventually, is then stripping that image back down for deployment.  Add to that the possibility that all was not well in the relations between the Smalltalk event loop and the application design/test/develope cycle for GUI applications.  Give Cincom VisualWorks a spin and you'll see that I can rest my case.  Smalltalk evangelists, just count to ten.  Relax.  Take a few deep breaths.

Metacello is finally a way for code users to be able to use modular code without resorting to chicken giblets in order to choose among package versions.

But why did this require some 3 generations of Smalltalk developers?  My view: that Smalltalk was not multi-paradigm (for no good reason) and so failed to embrace logic programming.

Logtalk for Prolog is interesting in this regard: it also required generations of developers to appear - it came with categories before Self traits were retrofitted to Smalltalk and it comes with messaging.

What I now must take seriously is the configuration management of Smalltalk-Self-Actor hybrid Io.

Note: packaging is finally coming to Rebol as Rebol3 (in alpha.)  Modularity of Falcon was re-thought prior to version 1.0 (still in the works.)

Languages lacking sufficient contributors and library versions to put to the test: ICON, Unicon, ObjectIcon.

And no, bragging abut hot-fixes does not serve to avoid a hard-look at Erlang in this regard.

Arguably the reason that open-source Smalltalk got to configuration objects before VisualWorks is the strength of their user/developer community.

In fairness to legacy Smalltalk, I found PVCS for Visual Smaltalk Enterprise to be quite adequate.

My view: that source versioning and build configuration were confounded for years in Smalltalk.  Separation of concerns.

Think of it this way: the developer wanting to try new language features and the manager trying to audit application feature testing of putative release X. Then throw in the ability of Smalltalk to genially load code at startup ... for years a matter of trust trumping governance, compliance and risk.

Is there a dissertation on how all this was managed at J.P Morgan?

Smalltalk essentials maxim: code gurus must not do builds; builders must rotate among junior developers under rotating senior mentors.

Smalltalk essentials maxim: never strip when you can assemble instead.

Smalltalk essentials maxim: builds are not self-documenting.

The only audit to trust is the outside audit.  Facts: often performance-tuning would be out-sourced; audit was most often not even performed, let alone out-sourced.  Fallacy: unit-testing removes need for audit.  Fallacy: code escrow is suitable resource for software audit of runtime applications.

First step: remove developers from the deployment task.

Clean linen may dry on trees, but it don't grow on trees.