James,

I know that some folks follow this development pattern, but it isn't the norm. 

I'm postulating that following this development pattern would be a "good thing" on multiple fronts, it should be the norm for getting started with any smalltalk platform... if individual developers want to build an image and never build from scratch again, then that is their choice, but I think it should be a choice rather than the standard practice ...

The idea of a micro-image is what appeals to me ... when you have a micro-image as a starting point it is much easier to consider and use alternate base library implementations which in turns make it easier to move the language forward ... it also acts as a forcing function for tools since you start having to consider that the tools aren't in your application issues which sorta brings us back around the the idea of Declarative Smalltalk I mentioned before ...

Dale

----- Original Message -----
| From: "James Robertson" <jarober at gmail.com>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Cc: "VWNC NC" <vwnc at cs.uiuc.edu>
| Sent: Saturday, January 28, 2012 5:46:48 PM
| Subject: Re: [squeak-dev] Smalltalk for small projects only?
| 
| Outside the micro-image, we use tools like that on the project I work
| on - I'll be talking about them at the STIC conference (and they are
| in the Cincom public Store right now, name BuilderBundle).
| 
| We start from visual.im
| 
| -- load Store tools
| -- load application code
| -- save development image
| -- build runtime image, save it
| -- compress the runtime (using VW tools)
| -- run tests, report on results
| -- copy all final files (dev image, runtimes, and reports) to a share
| drive location
| -- send email to specified recipient as to build results
| 
| That whole process could run on an automated basis, but we still have
| some process hurdles sitting in front of that.  Bottom line though,
| getting a clean build out of this process has been working for us
| for months.  To be honest, the idea of a micro-image isn't all that
| interesting to me.  Unless you're building for embedded/mobile
| platforms, having a 20 MB deployment image is a non-issue, and the
| base image (visual.im above) is already in a known state.
| 
| On Jan 28, 2012, at 8:30 PM, 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 ...
| > 
| > Dale
| > 
| > ----- Original Message -----
| > | From: mkobetic at gmail.com
| > | To: "Janko Mivšek" <janko.mivsek at eranova.si>
| > | Cc: "VWNC" <vwnc at cs.uiuc.edu>, "Squeak"
| > | <squeak-dev at lists.squeakfoundation.org>,
| > | Pharo-project at lists.gforge.inria.fr
| > | Sent: Saturday, January 28, 2012 4:38:27 PM
| > | Subject: Re: [squeak-dev] Smalltalk for small projects only?
| > | 
| > | "Janko Mivšek"<janko.mivsek at eranova.si> wrote:
| > | > Ralph Johnson in his InfoQ interview made an interesting
| > | > observation:
| > | >
| > | > 2:55 minute: "Smalltalk made an fundamental error ... image ...
| > | > you
| > | > can
| > | > build something with 4-5 people what 50 people can build in
| > | > Java,
| > | > but if
| > | > you take 200 people in Java ... it is really designed for small
| > | > systems
| > | > ...  "
| > | >
| > | > Are we because of the image really destined for relatively
| > | > small
| > | > projects and small systems (of Java 50 people project size)?
| > | 
| > | The "image" argument is one of the easiest to pick when you want
| > | to
| > | justify your xenophobic reaction to an unfamiliar environment
| > | you're
| > | about to enter ("... but they are green and have antennas...",
| > | never
| > | mind that the antennas may actually be useful for something). But
| > | there's nothing fundamental about Smalltalk that requires an
| > | image,
| > | c.f. there are a few Smalltalks that don't make you use one (e.g.
| > | Smalltalk/X). It's just frozen state, many IDEs and editors allow
| > | you to freeze their state (e.g. Eclipse workspace), it would be a
| > | royal pain having to reopen the files you were working on
| > | manually
| > | every time, wouldn't it.
| > | 
| > | I think the problem is that most newbies, when being introduced
| > | to
| > | Smalltalk, are immediately confronted with "the image" as if it
| > | was
| > | something fundamental, like they couldn't get any further until
| > | they
| > | grok it. But there's nothing preventing you from never saving the
| > | image. Just commit your source code (and it could just as easily
| > | be
| > | a common file based VC in the back there) and quit the image.
| > | Always
| > | start from a fresh one and load the code back in. In this mode
| > | there's (superficially*) no difference between Smalltalk and any
| > | other IDE, you write your code, you run it, debug it, commit it,
| > | etc. You can completely forget the image if you want, it's just
| > | that
| > | most seasoned smalltalkers (the ones doing the introduction) have
| > | learned to take advantage of the image and using it in all kinds
| > | of
| > | creative ways, so they want to pass the knowledge along and
| > | manage
| > | to freak the newbies out in the process.
| > | 
| > | (*) the real difference between Smalltalk and other IDEs, that
| > | may or
| > | may not be an issue in any particular case, is that the IDE runs
| > | in
| > | the same memory space using the same code base as the
| > | application,
| > | so your development can crash the IDE, while other IDEs prefer to
| > | crash on their own :-).
| > | 
| > | But I disagree that the image is some sort of technical obstacle
| > | to
| > | scalability, I think it's completely orthogonal. The only place
| > | where it's hard to ignore the image with the image based
| > | Smallltalks
| > | is deployment. At this stage the image is the "compiled object
| > | code", in the same sense that a shared library is "compiled
| > | object
| > | code". You can (and some do) deploy as a clean base image, load
| > | the
| > | application code on start and launch the application. That's no
| > | different from a java or python app, their base image is just
| > | burned
| > | into the VM. But it's so much easier to make that snapshot when
| > | all
| > | of this is finally loaded in memory and ready to run. It loads
| > | faster, there are no scattered files to hunt down in the dark
| > | corners of the filesystem, makes perfect sense in many (most?)
| > | cases. If people are freaked out that they don't need to mess
| > | with
| > | CLASS_PATH, or PYTHONPATH or what have you, well, it would be
| > | quite
| > | easy to "fix that", wouldn't it.
| > | 
| > | You could say that every piece of software "has an image". When
| > | it is
| > | loaded it initializes its runtime structures, lays them out in
| > | memory and starts running. Nothing fundamentally different from
| > | the
| > | base image case, the "image" is just burned into the executable.
| > | If
| > | the VM was simply embedded in every saved smalltalk image and the
| > | resulting file was turned into an executable, you can't really
| > | tell
| > | the difference. The image just wouldn't be portable anymore.
| > | 
| > | So I could agree that the image can be an obstacle to adoption if
| > | you
| > | rub it in people's face, but it can just as easily be mostly
| > | ignored. It's not significant unless you make it so in your
| > | development process.
| > | 
| > | 
| > 
| 
| James Robertson
| http://www.jarober.com
| jarober at gmail.com
| 
| 
| 
| 
|