...the blueSqueak pinkSqueak thing was mostly tongue in cheek, I wasn't
serious.  Also, I think the people producing the Squeak and Stable Squeak
releases have the sole authority to name it whatever they want, we can only
offer suggestions, opinions, and lengthy editorials.

Having said that, I would say that SqueakPro and PowerSqueak are not that
ideal either...after all, what's the alternative...SqueakAmateur and
WeakSqueak?  That's not accurate, nor is it good, but it is the conclusion
that someone new to the community might draw.

- Stephen



> -----Original Message-----
> From: Doug Way [mailto:dway at riskmetrics.com]
> Sent: Thursday, April 19, 2001 2:01 AM
> To: squeak at cs.uiuc.edu
> Subject: Pink Squeak (was Re: Stable Squeak?)
>
>
>
> "Pink Squeak" as the new name for the version of Squeak targeted
> toward business/commercial use?  Hmm, "Squeak" by itself is
> already a bit whimsical sounding, but this might push it a bit
> too far.  Why not go all the way and just call it "Golden
> Twinkie" or "Frosty Cuddles"? :)
>
> Okay, joking aside, I know you were referring to the blue-plane
> pink-plane thing.  And I agree that "Stable Squeak" is a pretty
> darn boring name.
>
> I'm not really sure what a good alternative is.  I suppose you
> could call it SqueakPro or something like that, but that has a
> sort of marketing drone feel to it.  PowerSqueak?  PipSqueak?
> I'm comin' up dry here... I got nothin'.
>
> - Doug Way
>   dway at riskmetrics.com
>
>
> Stephen Pair wrote:
> >
> > Since Stable Squeak is forking, maybe we should start
> distinquishing the two
> > forks as:
> >
> >    Blue-Squeak
> >         and
> >    Pink-Squeak
> >
> > Just to be a little less boring than "Stable Squeak." (no
> offense to those
> > that no doubt spent countless brainstorming hours to come up
> with that name)
> > :)
> >
> > - Stephen
> >
> > > -----Original Message-----
> > > From: Sarkela [mailto:sarkela at home.com]
> > > Sent: Wednesday, April 18, 2001 4:32 PM
> > > To: squeak at cs.uiuc.edu
> > > Subject: Re: Stable Squeak?
> > >
> > >
> > > Thanks for responding Michael. You may as well have read my mind.
> > > I will, however, address the same points in roughly the same order.
> > >
> > > I must apologize for not being more communicative. I have had
> > > other activities that demanded my attention. I am truly sorry.
> > >
> > > I recall a picture from my childhood of the "language tree". It
> > > was gnarly and had funny shoots... like the Finno-Ugric languages.
> > > I would hope that Squeak will develop its own branches. Perhaps a
> > > foundation could help archive, explore and nourish this tree.
> > > We can embrace variety and come away richer.
> > >
> > > Since this branch is favoring simplicity over features, it is
> > > smaller and simpler. Mainline Squeak can benefit immediately
> > > from the unit tests we have written. Over time SqC can incorporate
> > > our base changes, or come up with better solutions that address
> > > the same issues. In any event, the long term goal is to incorporate
> > > more and more of the base image functionality in the Squeak world
> > > tour environment as loadable source code. It will always lag
> > > the base in feature set. It may even support other experimental
> > > interface projects. Our points of view are the principle
> > > limiting factors. The goals of the Squeak world tour and SqC
> > > are different, but they are more complementary than conflicting.
> > > There is an interesting dynamic tension between production coding
> > > values and the values of experimental development. Both are crucial.
> > > I expect the development of each to be a co-evolution.
> > >
> > > Why should you expect more openness in the future? Because,
> > > the Squeak world tour has reached the stage of an initial release.
> > > Every effort is being made to avoid licensing issues and I have
> > > erred on the side of caution. This is in the final round of
> > > validation.
> > >
> > > Hopefully it will spawn a flurry of forks when it is released.
> > > We hope to facilitate moving functionality between forks in
> > > the code base.
> > >
> > >
> > > [|] John Sarkela
> > >
> > > Man ist vas er isst. ;-}> See you in Essen.
> > >
> > > > From: Michael Rueger <m.rueger at acm.org>
> > > > Reply-To: squeak at cs.uiuc.edu
> > > > Date: Wed, 18 Apr 2001 08:55:01 -0700
> > > > To: Squeak <squeak at cs.uiuc.edu>
> > > > Subject: Re: Stable Squeak?
> > > > Resent-From: squeak at cs.uiuc.edu
> > > > Resent-Date: 18 Apr 2001 15:55:57 -0000
> > > >
> > > >
> > > >
> > > > Andreas Kuckartz wrote:
> > > >
> > > >> I still do not see a need for a project fork which is not
> even prepared
> > > >> openly.
> > > > I agree with you that the work could have been more
> publicized, but...
> > > > The whole idea of Squeak is to encourage everyone to do
> whatever they
> > > > want. Interestingly both Alan Kay and Dave Thomas actually
> encouraged
> > > > people to do this in their keynotes at SmalltalkSolutions.
> > > > Standardization is stagnation, and we already have enough
> systems that
> > > > are standardized, haven't we? ;-)
> > > >
> > > >> Which of these features are incompatible with the aims of SqC ?
> > > > Actually none. And stable Squeak is not intended to be
> incompatible, the
> > > > idea (John correct me if I put this wrong) is to take a
> breath, take a
> > > > very close look at the system and work out some issues like
> modularity,
> > > > refactoring, cleanup of historically "grown" code that later will
> > > > benefit the "mainstream" Squeak tremendously.
> > > >
> > > >> Why should I expect more openness in the future?
> > > > Be patient just a little while longer.
> > > > And, the world tour is coming almost to your home town in
> August (ESUG
> > > > in Essen), for LA that would be considered walking distance (except
> > > > nobody would walk here ;-) ).
> > > >
> > > > Michael
> > > >
> > > >
> > > > --
> > > > "To improve is to change, to be perfect is to change often."
> > > > Winston Churchill
> > > > +------------------------------------------------------------+
> > > > | Michael Rueger    m.rueger at acm.org      ++1 (310) 937 7196 |
> > > > +------------------------------------------------------------+
> > > >
> > >
>