[squeak-dev] Re: What is Squeak (was Re: Re: package universes,
sake/packages, (first time) user experiences, etc.)
keith_hodges at yahoo.co.uk
Sun Dec 7 13:29:58 UTC 2008
The whole ethos behind 3.11 is to provide a framework for people to
If we get that right progress is assured. I admit I myself have had some
hiccups, I have had domestic problems, and lots of deadlines in my day
job. BUT, in a framework where people are encouraged and enabled to
contribute that shouldn't matter.
PROGRESS HAS CONTINUALLY BEEN MADE by someone somewhere, its just a
matter of harnessing it.
I am left with a huge sense of irony, given that the whole ethos behind
3.11 is to provide a framework for people to contribute:
Irony no. 1, the entire Pharo team create a fork. Benefit, Pharo guys
get to do R&D for us to "acquire" later, iff we can persuade them to be
co-operative (i.e. use similar tools and apis)
Irony no. 2 -
I have tried and tried and tried, to encourage you, ask you persuade
you, to bring your expertise and contribute, but you will not. You
You have expertise in unloading bits of squeak into separate packages. I
hate grovelling around looking for obsolete references. You have already
done the work. All that needs to happen is to package your work into
discrete #unload tasks, and Sake/Packages &/ Universes load tasks
If a project whose goal is to encourage people to contribute cannot get
people to contribute then it is doomed from the start.
> Andreas, you should take the challenge now.
> Nobody could say you don't know Squeak in deep as they could say to me.
> I tired of no progress,
I am fed up with you saying there is no progress. I do paid work in
squeak, and from that perspective there has been LOTS of progress. In
some ways Squeak was painful to use for commercial work. I used to
dread building up an image from scratch for a new client project, and it
was impossible to code several client projects simultaneously in one
image (due to MC bugs).
I am approaching the point where I can code all of my client projects in
one image, and automatically deploy to separate images for each client.
Things are getting much better than they were a year ago and as soon as
"Bob the Builder" is ready there will be a whole lot more progress.
LevelPlayingField - is a huge bonus
Monticello - 100's of fixes, huge speed improvements, Files support (I
Sake/Packages - Actually does work
Sake - Simple but ultimately very powerful.
Tasks - Framework for organising 3.11
Pharo - R&D for Squeak 3.1x
FunSqueak - R&D for Sake/Packages
SqueakLightII - R&D for Squeak3.1x
> only read about ideas but no evidence of going in
> the good direction.
But Edgar you have decided in advance not to be interested. You take one
look at the fact I embed small scripts in Mantis bug reports and you
refuse to contribute even there. You have never contributed one script.
Have you ever loaded a fix using Installer mantis ensureFix: 474 ? It is
actually very useful.
You tell me that all these guru people should be listened to, at the
same time you tell me I am not worth listening to. I have been coding
for 32 years, you never know I might know something after all, you might
learn something. Sorry I am not a professor in an academic ivory tower,
I am a pragmatic programmer, and for me perfectionism gives way to
This means that I appreciate the need for TEAM, I cannot do it on my
own. Matthew has been a huge help to me, dotting i's and crossing t's. I
wrote the code for atomic loading in Monticello 1.6 in December 2007.
Colin wrote the code for SystemEditor long before that. It is Matthew
who has had the patience to get SystemEditor to work as required through
painstakingly careful testing. So the irony no.1 is that many potential
team members have gone off to pharo, the irony number 2 is that other
potential team members are hankering after the same old way of doing
things and have dug their heals in.
Sure I might be wrong, and if I am, I would be happy to be shown a
better way. For 3 years the community has talked about a better way
would be led by improved tools, and greater modularity. Meanwhile
release teams have soldiered on declaring that "We are not going to
develop anything, just integrate what the community gives us". The
community has lacked the tools to give the release teams what they were
asking for. The lead time for a new bit of code to get into the image is
probably on average 3 years in a good year.
3.11 might look a bit slow of the mark, and I have my fair share of
excuses. BUT we are actually coding stuff, and coding stuff takes a bit
more time than cherry picking code that is already out there.
To be honest, all of my code works in 3.7, so from the pragmatic
perspective, the huge efforts put in by 3.8 3.9 and 3.10 teams to give
us incremental changes has not really been that radical, or even useful.
So from a pragmatic sense if 3.11 follows the same... "One person load a
few fixes and release an image" ethos, it is valueless to me.
At one point the Board/Oversight Team/Leaders(?) recognized this, and
felt that the effort was better spent on something radically new (i.e.
Spoon). I campaigned for 3.11 to go ahead because I knew we had a lot to
harness that would be really useful, and would be potentially be lost if
we didn't do it, not because I wanted 50 more random fixes in my image.
In contrast the ... "harness lots of creativity from lots of people, and
enable as much stuff to work as possible for everyone" ethos behind 3.11
will give me benefits, it will, and already has given me lots more
things to play with.
It is well known that technical projects never fail due to technical
reasons. Politics is always the make or break of any software, and I
dont do politics, I cant see much point in tact or diplomacy. If we fail
to make progress, I will blame the politicians.
Now you are on the board Edgar, that makes you a politician.
> The last good Squeak release with wide consensus was 3.8
Which is a fact of life
> Then come people who for his own (maybe good) purposes introduce Traits.
> You always said and I support still no evidence Traits give us some we don't
> could made with good Smalltalk.
> And introduce the troubles.
> Almost all major forks is no Traits (3.8) based.
And Matthew has done the work to make this a non-issue.
> But if nobody take the trouble to see how to go from existent Monticello and
> current image to smaller and modular, never we could reach any of it.
Perhaps I should change my name to "Nobody"
> I do my best, sometimes good and sometimes bad.
> Scripting people always could script it if they wish.
and Image tweaking people can always Image tweak if they wish. But their
work is more difficult to harness and cross fertilize between forks and
different sectors of the community. They have no ethos of desiring it to
be possible, and no means to transact it.
In contrast the scripting side of arguement goes like this:
3.11 is generated by a series of scripted tasks, but that script is
modular in such a way as to be useful to another fork, say Sophie. i.e.
we actively view other forks as part of the same moving forward process.
We support them, we don't leave them out on their own.
They can take a copy or a specialised subclass of the 3.11 set of tasks,
and apply them to their next release.
If all the forks, apply their core improvements via a common set of
tasks, and packages. And if all the forks use a common set of tools to
organise their work. Then they will naturally converge where it is most
important, where there is the most overlap.
There is a vision for the politicians to think about
More information about the Squeak-dev