On Sat, Jan 28, 2012 at 10:07 AM, Dale Henrichs <dhenrich at vmware.com> 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...
>

False.  We used change sets to exchange small deltas.  We constructed
base-line images (analogous to releases), but I never got an image from
someone else except as a context in which a bug was easily reproducible.
 By the late 90's we were using parcels to exchange components, and
composing the image from these components.


>
> 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 ...
>

I disagree.  If you've ever used e.g. svn to manage something even
medium-sized you'll find out it handles merge and distribution far worse
than e.g. Monticello or Store.  The main difference is definition-level
differencing and decomposition into components.  Typical copmponents in a
file-based system are spread over a set of files, often with components
tangling with each other in certain files.  This still happens in
Smalltalk, but to a lesser extent, being more manageable with package
overrides and e.g. schemes such as menu pragmas to provide soft integration
of overlapping components.



> 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.
>

This is a straw man.  Here's a scheme that works and scales.  Routinely
produce a new baseline image which has the accepted main line merged into
it.  People take this image, load their components into it and program
relative to it.  Then they commit to the central repository when ready
(being able to use their own local repositories for their own branches
etc).  This scheme has appeared in various guises, from the original
Smalltalk group (6-monthly baselines, meetings to decide the contents of
the base image) to e.g. weekly builds at Qwaq.


> 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:)
>

Personally I find Monticello significantly more powerful than mercurial or
svn, that I have a lot of experience with.  I disagree also that no-one has
focussed on the issue  Both Cincom has put in significant effort into
Store, and the Squeak community (yourself included) has put significant
effort into Monticello.


>
> 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 ...
>

Sure, but one can put together something for Smalltalk by hand in very
little time.  If you compare building an automated bootstrap for Smalltalk
(I just did one for Newspeak over the last few days) compared to using e.g.
ANT, there's not much difference, except that the Smalltalk one is easily
debuggable.

If there is a difference it is the self-containedness of Smalltalk vs the
catholicism of file-based tools.  Smalltalk falls flat on its face when one
wants to do ANT-like things that build other than purely Smalltalk
artifacts.  Things like ANT are far weaker but far more general tools than
their Smalltalk equivalents.  For me this comes dow to not enough emphasis
on Smalltalk as a platform, where platform is something that supports
integrating with the surrounding ecosystem.  In Squeak the FFI, file system
and external process interfaces are really weak.  A good challenge would be
to reimplement ANT (a Java application) in Squeak/Pharo.  That would force
us to address real weaknesses.


>
> Dale
>
>
>
> ----- Original Message -----
> | From: "Janko Mivšek" <janko.mivsek at eranova.si>
> | To: Pharo-project at lists.gforge.inria.fr, "Squeak" <
> squeak-dev at lists.squeakfoundation.org>, "VWNC" <vwnc at cs.uiuc.edu>
> | Sent: Saturday, January 28, 2012 7:46:32 AM
> | Subject: [squeak-dev] Smalltalk for small projects only?
> |
> | Hi guys,
> |
> | 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)?
> |
> | Are we really not able to scale to bigger projects/systems because of
> | that?
> |
> | Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but
> | still...
> |
> | [1] http://www.infoq.com/interviews/johnson-armstrong-oop
> |
> | Best regards
> | Janko
> |
> |
> | --
> | Janko Mivšek
> | Aida/Web
> | Smalltalk Web Application Server
> | http://www.aidaweb.si
> |
> |
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120131/171f6add/attachment.htm