Sven,

Keep in mind that I'm talking about making it possible for teams of 200 to use Smalltalk (or 20 teams of 10, or 20 teams of 4) ... 

How many Smalltalk developers rebuild their image from scratch multiple times per hour (day/month/year) during a development cycle ... If Smalltalk developers had to build their images over and over again on a daily basis, we would have had good tools for building images a long time ago:)

Because Smalltalk is am image it isn't necessary to build from scratch very often, but because we as a group haven't focussed on making it easy it is unnecessarily hard ... and building from scratch is a prerequisite to being used in large projects ... 

As I said, I don't think the problem is insurmountable...and I do think we are getting better.

It's just that if tomorrow a team of 200 walked up to my door and said they wanted my help in setting up their Smalltalk development environment, I'd gulp and say "give me a couple of months (at least)"...

Dale

----- Original Message -----
| From: "Sven Van Caekenberghe" <sven at beta9.be>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Cc: "VWNC" <vwnc at cs.uiuc.edu>, Pharo-project at lists.gforge.inria.fr
| Sent: Saturday, January 28, 2012 11:08:08 AM
| Subject: Re: [squeak-dev] Smalltalk for small projects only?
| 
| Dale,
| 
| On 28 Jan 2012, at 19:07, Dale Henrichs wrote:
| 
| > Janko,
| > 
| > I think the limitation for Smalltalk lies in source code management
| > tools/styles ...
| > 
| > With a file-based language 200 engineers can contribute to the
| > project ...  each engineer can checkout a version of the system
| > work in isolation then commit his or her work to the shared
| > repository resolve conflicts and move on .... other engineers can
| > easily integrate the work and so on ... the source code management
| > tools scale ...
| > 
| > In the mid nineties at ParcPlace systems the image was passed
| > around from engineer to engineer so that he or she could integrate
| > their work into the production image... this doesn't scale...
| > 
| > There have been proprietary source code management tools that have
| > been created over the years. You can bet that the large companies
| > that are invested in Smalltalk are using systems that are based on
| > these proprietary systems, but you can also bet that they've had
| > to customize those systems for their needs...
| > 
| > The file-based SCM systems work out of the box and don't care what
| > language or even development process that is being used ... they
| > are managing files ...
| > 
| > There is no standard SCM for Smalltalk and none of the file-based
| > SCMs really fit Smalltalk. When we are arguing about whether git
| > or mercurial is better on the Pharo list, I will retract that
| > statement:).
| > 
| > Without a standard SCM, the first thing that a 200 person
| > engineering groups needs to do to start using Smalltalk is figure
| > out (for themselves) how to share their work and keep 200
| > individual images in synch ... I'm not necessarily convinced that
| > anyone has really solved this one.
| > 
| > Personally I believe that the problem is surmountable, but for
| > whatever reason the Smalltalk community hasn't focussed on
| > seriously addressing the SCM issue .... in the last 30 years or
| > so:)
| > 
| > Being able to repeatably build images based on a minimal core image
| > is certainly headed in the right direction, but we still have a
| > ways to go on the tools front ...
| > 
| > Dale
| 
| I want to respectfully disagree (and I even don't understand some of
| your remarks, or the underlying implications, given your excellent
| work on Metacello and some much other contributions to Smalltalk).
| 
| Yes, the very old way of passing images around was arcane and did not
| scale (I did this too in the 80'ies early 90'ies).
| 
| But today, with Monticello and Metacello things are quite different,
| not perfect but totally acceptable.
| 
| When building Smalltalk applications I am using code written by
| hundreds of people during tens of years, this works out very well.
| 
| In traditional file bases language like Java or C using a traditional
| SCM, you will immediately hit problems when even a couple of people
| work on parts of code that are closely related. Merging, branching,
| solving conflicts there is no different than with Monticello, IMHO.
| 
| Organizing big teams is plain hard, in any language. Clear
| separations/responsabilities/interfaces are the only answer.
| 
| Sven
| 
| 
| 
|