[squeak-dev] Squeak 4.x should adopt Pharo 1.0

Dear All,

As far as I see it the only sensible way ahead for squeak 3.11 is to
adopt Pharo 1.0 as the next base version of squeak (i.e. 4.0), and to
begin a series of initiatives to promote compatibility with squeak
pieces that pharo doesn't support.

The previous squeak 3.11 vision accepted, and now rejected, by the
squeak board was to develop a process that would allow squeak to harvest
the contributions of all the other forks, or other major initiatives,
and for significant contributions to be shared by all the forks.

All of a sudden there was an "oh no pharo is ahead of us" panic that
ensued last month as a result of new squeak-dev people that were not
involved in, nor seemed aware of the goals of the 3.11 process. Within
this process Pharo may simply be viewed as a research project carried
out on behalf of the wider squeak community, that will be harvestable in
good time.

However now that this idea is no longer going to be developed, we need
to limit the number of diverging active forks as much as possible,
rather than creating new ones ("trunk" makes the problem worse not
better). Once the output of "trunk" is released in whatever form we will
then have yet another base image to manage code for, and I don't think
that that is an acceptable outcome.

When it comes to the elections next year, if there is anyone who would
like to run on the "Squeak to adopt Pharo" ticket, then I will vote for
them.

best regards

Keith

p.p.s. Bob is not going to be released as open source, if you would like
the ability to build your images daily, and run the test suites against
your deliverables, then please do email me for licensing terms.

El lun, 10-08-2009 a las 21:07 +0100, Keith Hodges escribió:
I don't agree with you on this point. Pharo has its own merits to exists
and it didn't fork as a "research project" for the squeak community.
As its web page states, its goal is:

"to deliver a clean, innovative, open-source *Smalltalk*"

emphasis mine. Not a clean Squeak.
As the day pass the foundations grow stronger and itself gains more and
more identity and independence. This, if nothing really big happens on
Squeak, will attract more developers and new users. There is no date yet
to deliver a new version of Squeak, and this, together with the Pharo
1.0 release, will be less energy to try to maintain code for several
forks and several packages will choose to support the one with more
*apparent* users.
What I want to say is, there is, as each day pass, less homesick for the
past and more joy for the future.


>
> However now that this idea is no longer going to be developed, we need
> to limit the number of diverging active forks as much as possible,
> rather than creating new ones ("trunk" makes the problem worse not
> better).

This is a point that I have never accepted of your thesis. There is no
way to put all the "forks" in the same
process/mindshare/goals/repositories. It is impossible. Even if they do
it just for upsetting people. This isn't going to happen.

The forks, as the young people, want to be free, independents, of its
parents. They don't want to be like their parents project but a little
different. They WANT to be better (whatever this means to the fork) and
independent. They want to learn their own lessons.

If for accident they happen to be compatible good, but if not, well, as
the Linux community can show, there can not be a single distro neither a
single code base that runs in every distro. How they solved it, by
assinging mainteiner of each package that tracks the upstream project
and adapt it to the specific distro. Something like this will happen
with squeak/pharo/cuis. The upstream developers will have its
development platform but someone else will adapt it to other platforms.



> Once the output of "trunk" is released in whatever form we will
> then have yet another base image to manage code for, and I don't think
> that that is an acceptable outcome.
>
> When it comes to the elections next year, if there is anyone who would
> like to run on the "Squeak to adopt Pharo" ticket, then I will vote for
> them.
>

If this happen, then good for both of the communities. But until this
happen, most new users will learn by the lists about pharo and when
trying and comparing it to squeak, will make its choice. Some of them
will stay with squeak, some of them will try again squeak when a new
release is made and some of them will stay with pharo for ever.

One (at least me) can't be jumping or using several smalltalk versions
(the same way that I don't like to administer linux of several flavors,
it add unnecessary complexity and work).

> best regards
>
> Keith
>
> p.p.s. Bob is not going to be released as open source, if you would like
> the ability to build your images daily, and run the test suites against
> your deliverables, then please do email me for licensing terms.
>

This is really a sad thing to read. Of course it is your decision, bad
for us as it sound as Bob was a very good piece of software. On the
other side, this sounds also like a emotional response more than a
rational one. But if the community can't use your code, well, like the
BitKeeper on the Linux kernel code case, someone will have to think
something.


--
Miguel Cobá
http://miguel.leugim.com.mx

Miguel Enrique Cobá Martinez wrote: Pharo forked with exactly the same goals for its own core as we had for
3.11, to be smaller and leaner. The only goal that it didn't share was
that of backwards compatibility, and for that Installer's
LevelPlayingField provides us with a process for handling some backwards
compatibility issues, and Sake/Packages has slots for the rest.

We had a couple of other longer term goals, like that of being able to
replace the UI or other major subsystems with atomic loading.
(Morphic1.0 to morphic 3.0 for example). Thus we expected squeak to
evolve by revolution using completed innovations, rather than by
evolution as pharo was doing. Now pharo is done, lets just use it, for
them it is a series of evolutionary steps, for us it is a single
revolutionary step served to us on an MIT shaped plate.

For squeak post 3.11 with our new process in place it would have been be
trivial to try out new versions of squeak built upon some core packages
stolen from Pharo. I fully intended to have squeak 3.12 built and tested
upon Pharo's network and collections for example. A gripe that I have
with Pharo is that they never developed anything with anyone else in
mind in order to make such a process easier but once Pharo is delivered
you can see exactly what is needed after the fact.
> emphasis mine. Not a clean Squeak.
>  
I fully understand that Pharo doesn't want to be a Squeak.

However for the majority of Squeak users we build applications on top of
squeak, and we couldn't care less about what is in the core image it
might as well be the same core as pharo core. The only reason that I
ever meddled with squeak core in the first place was because release
teams always ignored the fixes that I proposed. However all of my own
fixes are in pharo (thanks Damien) , so now I don't care about the core
for my application work anymore.
> As the day pass the foundations grow stronger and itself gains more and
> more identity and independence. This, if nothing really big happens on
> Squeak,
Squeak is in self destruct mode at the moment for various reasons.
>  will attract more developers and new users. There is no date yet
> to deliver a new version of Squeak, and this, together with the Pharo
> 1.0 release, will be less energy to try to maintain code for several
> forks and several packages will choose to support the one with more
> *apparent* users.
> What I want to say is, there is, as each day pass, less homesick for the
> past and more joy for the future.
>  
It boils down to the fact that neither I nor do many others want to have
to maintain loadable packages for more than one core implementation.
>> However now that this idea is no longer going to be developed, we need
>> to limit the number of diverging active forks as much as possible,
>> rather than creating new ones ("trunk" makes the problem worse not
>> better).
>>    
>
> This is a point that I have never accepted of your thesis. There is no
> way to put all the "forks" in the same
> process/mindshare/goals/repositories.
I never said there was... that was never the expectation, in fact the
3.11 process was designed to provide the opposite, the ability to build
and test a hypothesised image from multiple disparate sources, this
making it easier for all forks to pick and choose, and to migrate. Then
we stood a chance of everyone migrating to the best of the best, rather
than everyone sticking with the mediocrity that they had inherited.

However I did succeed in getting all of the code loading tools to work
equally well in all of the forks so that code could actually be shared
and ported easily. I maintain something like 19 projects on
squeaksource, so this is essential. However for some strange reason no
one else who matters in core development land (Andreas/Stephane) appears
to care in the slightest about essential common tools.
> It is impossible. Even if they do
> it just for upsetting people. This isn't going to happen.
>
> The forks, as the young people, want to be free
But squeak isn't a fork, squeak is the mother, and mothers always try to
keep their family together and on talking terms. Exactly.
> This is really a sad thing to read. Of course it is your decision, bad
> for us as it sound as Bob was a very good piece of software. On the
> other side, this sounds also like a emotional response more than a
> rational one. But if the community can't use your code, well, like the
> BitKeeper on the Linux kernel code case, someone will have to think
> something.
>
>  
I can't live on thin air, neither can I afford to have the piss taken
out of me. The majority of the board make their livings out of squeak,
yet I have donated 3 years of weekend-work towards squeak for free. I
was in some considerable financial difficulties when the board sprung
this on me, having had a project completed but abandoned by the client
without paying up. As I see it finding a paying client for Bob is the
only practical way I can think of redeeming anything out of this situation.

best regards

Keith

> without paying up. As I see it finding a paying client for Bob is the
> only practical way I can think of redeeming anything out of this situation.
>  
And apart from commercial work, I am withdrawing from anything that
doesn't directly pay a bill. When I am flush I may reconsider, but for
now my free time will be spent with my counselling and book writing
projects. I have the board to thank for showing me the error of my ways.

Nevertheless I do think that the squeak community need to re-think this
whole board thing. Plainly voting for an ad hoc group on a yearly basis,
and giving them an unspecified amount of authority to be as
inconsiderate as they want to be, is turning out to be rather a high
risk strategy.

Keith

good summary :)
We started pharo because we could not move anymore.
We will continue to pay attention to what they other forks are doing.

Stef

On Aug 10, 2009, at 11:10 PM, Miguel Enrique Cobá Martinez wrote:

Stéphane Ducasse wrote:
> good summary :)
> We started pharo because we could not move anymore.
> We will continue to pay attention to what they other forks are doing.
>
>

BTW, some of us Second LIfe types are starting to play with
Pharo/Seaside and various little issues keep popping up. I'm a total
Smalltalk
noob, but when I can't work through an example from the Squeak by
Example book, that suggests there's some interesting features that should
be looked at...


Lawson
>
>

Lawson English wrote:

> BTW, some of us Second LIfe types are starting to play with Pharo/Seaside
> and various little issues keep popping up. I'm a total Smalltalk
> noob, but when I can't work through an example from the Squeak by Example
> book, that suggests there's some interesting features that should
> be looked at...

In my experience, some issues may simply be things that are broken due
to things being in an unfinished state.  Others are deliberate
changes, even beginning as early in the newcomer experience as the
author initials and name dialogs (which subsystem, coincidentally,
remained unfinished when I downloaded Pier 1.1.1 last month.)

You may be aware that several of the 'Squeak by Example' contributors
now spend a lot of time on the Pharo project.  I understand that the
next edition may be based on a Pharo image, so I expect that Oscar
_et_al_ remain willing to accept "Pharo" patches to the text at
http://www.iam.unibe.ch/mailman/listinfo/sbe-discussion (very low
traffic)

Hope that helps.  David