Hey all!

On 01/29/2012 02:30 AM, Dale Henrichs wrote:
> Martin,
>
> Very good points ... So here's a little riff on:
>
>    "Always start from a fresh one and load the code back in"
>
> Just imagine if the standard Smalltalk development experience started with a micro-image (a compiler and not much else) and then went through the following steps:
>
>    1. decide which base image (thing choosing between Squeak 4.3
>       and Pharo 1.3) to use for development
>    2. run image build script starting with the micro-image that
>       produces a deployment image and a development image
>    3. fire up development image and write code using all of the
>       nifty in-image development tools
>    4. committing your work involves saving your code and updating
>       the build script
>    5. either continue development at step 3 or go back to step 2.
>       If the project is successful, there may be demand to actually
>       run on multiple platforms (Squeak 4.3 and Pharo 1.3 or Squeak
>       4.3 and Squeak 4.4), but then it should be as easy to build two
>       sets of images as it is to build 1
>
> If this were the standard development process for Smalltalk, I think that the SCM tools would be much better overall (the more engineers experiencing pain, the more chance that someone will decide to fix problems) and I think (as you imply) that Smalltalk would be easier for newbies to pick up on their own, since there is a familiar process and the illusion that programs are being created ... and oh yeah that 200 developer team would have the opportunity to fail miserably while using Smalltalk ...

Now... the above model is exactly what we used in Gjallar. We used a 
build script using Installer (Metacello was not around - and frankly, 
Metacello seems so... complicated to me) and a base image, trivially 
simple but worked fine.

Aother "silly simple trick" was that I took the role as "trunk" so 
everyone knew that gk-snapshots were regularly picking up other people's 
contributions. This took some "merge load" off people.

But I can't really see why any reasonably large project would *not* use 
a process similar to this, and I can't see how this would "force our 
tools to improve" either.

regards, Göran

PS. The process worked fine but our team was never that large. Yes, we 
started feeling the "scale problem" with MC, but the fact that you get 
away with "larger commits" with MC took off some of the pain. Though of 
course not optimal, smaller commits would of course be The Right Thing.