Howdy folks, just a few remarks embedded below ...
--- ducasse stephane <ducasse at iam.unibe.ch> wrote:
> Hi all 
> 
> have you noticed that nobody uses anymore the
> companion list
> modsqueak at bluefish.se
-- for at least one of us, that's the only source of
Squeak news these days ...

[...]
> >> Your work and the ModSqueak work seem quite
> similar in scope. Can you
> >> comment on the differences?
> > 
> > While they may appear similar, if you look a
> little closer at
> > ModSqueak/Ginsu, they are actually quite different
> in their approaches.
> > Theirs doesn't use namespaces/modules at all (yet
> at least), and instead
> > uses the declarative/semantic model of Team/V that
> Allen W-B described,
> > which in its principles is very similar to how
> traditional compilers and dev
> > tools operate. However, a closer comparison would
> get argumentative and I'll
> > try to avoid a flame war here.
-- aw, c'mon, how could it possibly be any worse than
what went across the PPD intranet a few years back?
<grin, duck and cover>

The fundamental concept to look at is, a Smalltalk
development image is a very dynamic, interactive,
reflective environment.  Most of us are so used to
this we take it for granted.  But if you step out and
do some Java programming, for example, you'll know
what you're missing!

But on the other hand, at the very instant you deliver
a runtime (end-user) piece of software, all that
becomes (more or less) irrelevant.  A delivered
program is a static beastie, in that one does not
expect to query its internals, and one does not expect
to need to change its behavior from one run session to
the next.  At that point, it makes perfect sense to
take advantage of all that "traditional" stuff.

[...]
>  I think
> > it was Paul who said that they are developing
> their solution because it is
> > the kind of tool they want to use for their own
> work, which I respect, but
> > to adapt it to the usage patterns and needs of the
> Squeak community would
> > not be a straight-forward thing to do at all. I
> have explicitly taken the
> > needs of the Squeak community into account, and
> tried to design a model that
> > is specifically adapted to this, adopting the good
> features from the
> > suggestions of people here, including from the
> ModSqueak/ Team/V approach.
> > 
> 
> I really have the impression that there is a
> ***big*** miscommunication her
> and I'm sad about that. I think that there is
> nothing in team-V/Envy like
> model that prevent internet based solutions.  I do
> not see a real problem.
-- yep, looks to me like there's been some
miscommunication, and I'm probably responsible for
part of it.  Folks, I tend to have only about time to
blister out emails as fast as I can type ... apologies
if that sometimes gives the wrong impression.  Squeak,
with its community, is all-in-all one of the best
things I've seen happen in software recently.  Any
Squeak work I do, I will be happy to share, and
feedback is always welcome.  Especially negative
feedback, frankly.

Anyway, I don't recall exactly what I said, but my
intent was to point out that if the community chooses
not to adopt "ModSqueak", then I'm not terribly upset
about it because I simply want a development/delivery
platform.  Given my career history (Digitalk,
ParcPlace-Digitalk, exobox, among others), if I got
all upset whenever a piece of my work gets deleted
just after completion, I would be sitting in a padded
room wearing a very long sleeved garment and giggling
a lot.  Not to mention, typing with my toes.

That said, one of the fundamental priciples which has
underlain ModSqueak from the start is, as with Team/V,
"don't inhibit normal Squeak [Smalltalk] work".  By
comparison Envy, bless its heart, can really get in
the way when all you want to do is program in the
image like you're used to doing.

When I use ModSqueak, I do not have to drastically
alter my usage patterns.  I tend to prefer the
ModSqueak browsers, but (due to some lacking features)
I also often switch over to the SystemBrowser (?), and
I code frequently in the debugger and
senders/implementors browsers, and all those normal
tools.  Changesets are still recorded, and can be
filed in/out as normal.  So I'll assert (feel free to
convince me otherwise):  the ModSqueak tools do not in
any way inhibit normal Squeak usage patterns, thus no
adaptation would be necessary.

Note, however, that as I'm not caught up on namespaces
or environments, I could easily be missing something
here.

> I have the impression that there are two aspects
> here (allen sent an email
> with the same distinction)
> 
>    - one that is how do you identify versions of a
> group of class with
> visibility checking, so this is Envy/Teamv 
> Applications for example with
> some variations. This approach is more class-based
> from my perspective. We
> manipulate abstractions and not instances of the
> classes themselves.
-- imho, this might be more correctly stated as
pertaining to "definitions" rather than "classes".  In
Team, Envy, and ModSqueak, I have frequently found it
handy to be able to work in a module that contains no
class definitions at all.

>    - one that is more binary component oriented. We
> can send around living
> object with their class or may be an identification
> of the previous
> abstraction.
-- binary gets a bit trickier, as you want as little
class/abstraction information as you can get away
with.  This, for example, necessitated a good bit of
extra work at Digitalk to maintain version-to-version
upgrade paths for PARTS and SLLs (link libraries). 
Any time a class shape changes, objects derived from
that class will need to be rebuilt, or mapped, or
replaced, or hit over the snout with a rolled up
newspaper in complete frustration.  But it's hardly
impossible; GemStone has been solving this problem
quite well, for 15+ years now.

> Then I have the impression that namespaces can or
> cannot be implied into both design (I do not know
the > tradeoff and pitfalls). I think that this is
> orthogonal.
-- seems orthogonal to me.

>Sorry to say that again but I do not see why a
>Envy/TeamV model would
>prevent us to have internet base development.
-- it absolutely wouldn't.  In fact, one of the
original intents behind ModSqueak was to support just
that.  Afaik, we have not made any particular
presumptions w/r/t distribution, networking, etc. 
Joseph demo'd at ESUG on multiple machines, for
example.  The problems of concurrency, check-in, and
all that would still need to be solved; this is why we
had thought to delegate to a standard tool such as
CVS.

>What you cannot with a Envy model is passing objects
>in the sense of
>project or imageSegment. For this you need to define
>what is the component
>model you use, if you want to embed threads, objects
>fr example for having mobile code...
-- if I understand this point correctly, I disagree
somewhat.  Team and (later?) Envy provided enough api
hooks to allow the expert user to extend the system to
version/manage arbitrary objects as well as those
containing source code.

Ok.  Despite the impression I've probably given, I'm
not trying to "plug" for ModSqueak, and *especially*
I'm not trying to pitch it as better/worse/etc. than
any other work that's being proposed.  I have not had
time to do an adequate survey of what's out there now,
I'm <sniff! sob!> no longer a full time Professional
Squeaker, and there is great value to adopting work
that is actively supported, rather than waiting for
someone like me to get off my duff and Squeaking again
- I intend to, but can't promise.

But Allen, Dave, and members of the Camp Smalltalk
gang, just to name a few, have thunk this stuff
through at great length, and in many cases published
the work.  Add in the aggregate decades of real-world
production Smalltalk experience, and I have to concur
with Stephane that, at least, we should not disregard
the concepts and/or conclusions lightly.  Squeak has
*huge* advantages over other comparable software, but
there's no shame in looking outside the Squeak/ST80
tradition to empower it even more.

</soapbox>

Just my 2 monetary units, as usual in far too many
words ...
Paul

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/