[Pharo-project] [Smalltalk for small projects only?

Steve Wart steve at wart.ca
Sun Jan 29 17:29:32 CET 2012

Big legacy projects are still using Envy for VisualWorks less for the
reasons listed below, but mostly because it's extremely difficult to
migrate to Store without doing a "big bang" and most of these projects
don't have 200+ developers anymore anyhow (disclaimer: I'm only familiar
with 2 or 3 of these "success stories"). Many of the big Smalltalk projects
were mostly done using Envy, and it's a powerful tool, in spite of its
limitations. If there was a reliable way to move the latest changes from a
set of Envy configuration maps into Store, it would make it much easier to
get away from ancient, buggy and unsupported SCMs (like Envy/GemKit).

But I confess I am not a big fan of Store. It works and has some good
features, but it's VW-only and the model is not acceptable for modern
development practices, never mind security issues and whatnot.

I would like to know better what Ralph was talking about in this interview.
It's hard to generalize about this sort of thing without starting a huge
rambling flame war or similarly unenlightening cascade of posts.

I would personally like to see a git backend for Smalltalk that works
across all dialects. VisualWorks really threw a monkey wrench into things
by adding proprietary extensions but as we've seen with Seaside, if there's
a common need, the community can rally together and come up with some
reliably mechanisms to support all versions of the language.

How would git work? Source code in files, how quaint, and all that?

I don't think it's that hard. In Smalltalk a compilation unit is a method,
so you store one file per method. Get rid of the changes file. Index things
so everything doesn't grind to a halt.

Maybe I'm missing something, but I think this is the way to go. Are there
any fundamental problems with this approach (other than resources and
funding and the usual perfectly valid excuses)?


On Sun, Jan 29, 2012 at 7:09 AM, Philippe Marschall <kustos at gmx.net> wrote:

> On 28.01.2012 21:16, Janko Mivšek wrote:
>> Dale,
>> I agree with you that source code management is where we are weak. A
>> process therefore, as James already said.
>> In SCM  VisualWorks is ahead in my opinion, even that Store is also not
>> perfect yet. But it would be useful to reuse some of ideas in Monticello
>> based SCM tools too. With Metacello we got a good packaging tool, so,
>> where to go to be even better? I think SCM tool integration into code
>> browser can be next and relatively easy step. As Store is integrated
>> into VW code browser.
> Wow, Store. Did you know that Store is so bad that some of the biggest
> Cincom success stories paid a really huge, undisclosed sum so that they
> don't have to use it?
> If something cries 1995 then it's handing a SQL connection to the client.
> Your "interface" is the database schema. It ties the database schema to the
> client. You change the schema and you have to update all of the clients
> unless you "fake" the old schema with updatable views (if your RDBMS even
> supports this) and give the changed tables new names.
> Also security becomes more or less impossible to do. Once you have write
> access to the public Store repository you can more or less do anything you
> want to do on any project unless implement it using triggers. And then
> there are all the possible DoS attacks like SELECT FOR UPDATE.
> Cheers
> Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20120129/eaefa761/attachment.htm>

More information about the Pharo-project mailing list