<br><br><div class="gmail_quote">On Sat, Jan 28, 2012 at 7:07 PM, Dale Henrichs <span dir="ltr">&lt;<a href="mailto:dhenrich@vmware.com">dhenrich@vmware.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Janko,<br>
<br>
I think the limitation for Smalltalk lies in source code management tools/styles ...<br>
<br>
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 ...<br>

<br>
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&#39;t scale...<br>
<br>
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&#39;ve had to customize those systems for their needs...<br>

<br>
The file-based SCM systems work out of the box and don&#39;t care what language or even development process that is being used ... they are managing files ...<br>
<br>
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:).<br>
<br>
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&#39;m not necessarily convinced that anyone has really solved this one.<br>

<br>
Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn&#39;t focussed on seriously addressing the SCM issue .... in the last 30 years or so:)<br>
<br>
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 ...<br>
<span class="HOEnZb"><font color="#888888"><br>
Dale<br>
</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>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.<br>
<br>Karl<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
<br>
----- Original Message -----<br>
| From: &quot;Janko Mivšek&quot; &lt;<a href="mailto:janko.mivsek@eranova.si">janko.mivsek@eranova.si</a>&gt;<br>
| To: <a href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a>, &quot;Squeak&quot; &lt;<a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</a>&gt;, &quot;VWNC&quot; &lt;<a href="mailto:vwnc@cs.uiuc.edu">vwnc@cs.uiuc.edu</a>&gt;<br>

| Sent: Saturday, January 28, 2012 7:46:32 AM<br>
| Subject: [squeak-dev] Smalltalk for small projects only?<br>
|<br>
| Hi guys,<br>
|<br>
| Ralph Johnson in his InfoQ interview made an interesting observation:<br>
|<br>
| 2:55 minute: &quot;Smalltalk made an fundamental error ... image ... you<br>
| can<br>
| build something with 4-5 people what 50 people can build in Java, but<br>
| if<br>
| you take 200 people in Java ... it is really designed for small<br>
| systems<br>
| ...  &quot;<br>
|<br>
| Are we because of the image really destined for relatively small<br>
| projects and small systems (of Java 50 people project size)?<br>
|<br>
| Are we really not able to scale to bigger projects/systems because of<br>
| that?<br>
|<br>
| Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but<br>
| still...<br>
|<br>
| [1] <a href="http://www.infoq.com/interviews/johnson-armstrong-oop" target="_blank">http://www.infoq.com/interviews/johnson-armstrong-oop</a><br>
|<br>
| Best regards<br>
| Janko<br>
|<br>
|<br>
| --<br>
| Janko Mivšek<br>
| Aida/Web<br>
| Smalltalk Web Application Server<br>
| <a href="http://www.aidaweb.si" target="_blank">http://www.aidaweb.si</a><br>
|<br>
|<br>
<br>
</div></div></blockquote></div><br>