[squeak-dev] Smalltalk for small projects only?
karlramberg at gmail.com
Sat Jan 28 19:39:22 UTC 2012
On Sat, Jan 28, 2012 at 7:07 PM, Dale Henrichs <dhenrich at vmware.com> wrote:
> 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 ...
> You are talking about dealing with source code, but what about the live
objects in the image? Is there any work done on managing live images with
several developers ? This is where Smalltalk excels and would be very
interesting instead of falling back to the rebuild from source strategy.
> ----- 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...
> |  http://www.infoq.com/interviews/johnson-armstrong-oop
> | Best regards
> | Janko
> | --
> | Janko Mivšek
> | Aida/Web
> | Smalltalk Web Application Server
> | http://www.aidaweb.si
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev