[Pharo-project] [squeak-dev] Smalltalk for small projects only?
bschwab at anest.ufl.edu
Sun Jan 29 00:04:56 CET 2012
"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."
No, it's cool, it's EASY. "You just" check in your code and merge it. How dare you suggest that ****anything*** could go wrong during this sacred maneuver. If it does, just change SCM and blame the old one. By the time anyone figures out it did no good at all to switch, you've been promoted. Cool, eh?
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven at beta9.be]
Sent: Saturday, January 28, 2012 2:08 PM
To: The general-purpose Squeak developers list
Cc: VWNC; Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only?
On 28 Jan 2012, at 19:07, Dale Henrichs 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 ...
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.
More information about the Pharo-project