Re:Do you think that squeak is long overdue for a Refactoring only pass.

Do you think that squeak is long overdue for a
Refactoring only pass.

Hi Stef, Cees and Others interested in this.

Some great feedback.

Summary,

Refactoring would be good.

Doing it in 3.9 would not get it the proper energy.

There is a conflict about whether to refactor with
traits.

Withdrawing from supporting Etoys needs to be thought
about.

----
My reaction:

Version numbers are cheap. 3.9, 3.10, 3.11, 3.12, can
be had for a dime a dozen. Its patience that's dear.
All things can be done incrementally.

Seeing a traits refactoring would be interesting as an
experiment and risky to the development enviornment. I
would like to have a good refactored smalltalk version
to launch a traits refactoring from. The former won't
slow down the latter it would probably make it easier
and cleaner. At the end point of the traits refactor
increment we will have more info about our pleasure
with using traits. Which is why it is a good
experiment. A decision to keep it or revert back could
be better made at that time. We will not save anything
by not making the experiment.

Then we pick a version to make bug fixes to.

And then we go back to expanding again.

The crews to do the first refactoring and the second
traits refactoring should be different. And I don't
think the feature lovers of 3.9 should head the effort
to just reorganize things. We have to find someone
with the enthusiasm for that task.

Ditto for the traits refactoring though I can hear the
energy for that in the list already.


What will happen to Etoys?

I heard a recent speech of Alans which made his
strategy clear. You don't need to convince the adults.
If you sell your idea to children and just wait you
will eventually have enough adults on your side.  And
you sell to children by making things a 'toy' or a
'game'. The concept (not the implementaion) of etoys
is important to the future of squeak because adults
are important to the future of squeak and the future
adults are children now.

The MIT scratch project will release something this
spring.

And it seems to me that more thought must be given to
the needs, desires, and motivation of the squeakland
community. As I listen to what I hear on squeakdev I
get the sense that they are "strangers" to us now. Why
is this? How did it come about? Even if we are to go
our separate ways we need to know why.

Patience and curiosity will bring us information.
Information will beget knowledge. And knowledge will
guide us.


A suivre

Yours in service -- Jerome Peace

 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

On 25.01.2006, at 09:30, Peace Jerome wrote:

>
>
> And it seems to me that more thought must be given to
> the needs, desires, and motivation of the squeakland
> community. As I listen to what I hear on squeakdev I
> get the sense that they are "strangers" to us now. Why
> is this? How did it come about? Even if we are to go
> our separate ways we need to know why.


This was the decicion of the people behind SqueakLand.

It's not only towards squeak.org (were you can argue
that people are too focused on research and engineering).

But Projects like Smallland (who has the same children-focus)
found it impossible to cooperare with squeakland, too.

I personally am quite, how to say it, sad about this, as I am
a big fan of the "Dynamic Medium for all Ages" Idea. But
you can't force them to talk to you, in the end it's purely their
desicion.

We are now trying again an active move (from our side) to look
at all the bug-fixing that is done in the squeakland fork. A lot of
that seems to be quite important especially for the m18n things.

(I wonder if they have kind of private 3.8.1 for all related projects  
like
Tweak, Sophie, Croquet, Impara... it would be quite strange not to
share to work of bugfixing basic stuff)

      Marcus

Peace Jerome wrote:
> And it seems to me that more thought must be given to
> the needs, desires, and motivation of the squeakland
> community. As I listen to what I hear on squeakdev I
> get the sense that they are "strangers" to us now. Why
> is this? How did it come about? Even if we are to go
> our separate ways we need to know why.

I'd say it's mostly because the Squeakland community is to 98% educators
and to 2% computer scientists. Squeak-dev is pretty much the other way
around. Most of the people who use Squeak in an educational setting
don't care about the tool - they care about the purpose that they apply
this tool for (education). Contrast this with Squeak-dev: Here, it's all
about the tool and hardly ever about what purpose it is applied to. And
yes, I think it's correct that for most people in the Squeakland
community the gobbly-gook that goes across on Squeak-dev is pretty
strange. So is, for many people here, the thought to discuss how and
where a Squeak-based curriculum relates to some state standard.

Cheers,
   - Andreas

Am 25.01.2006 um 09:50 schrieb Marcus Denker:

> We are now trying again an active move (from our side) to look
> at all the bug-fixing that is done in the squeakland fork. A lot of
> that seems to be quite important especially for the m18n things.

Indeed. These fixes came from the Japanese Squeakers community and  
have been integrated in the Squeakland image.

As Michael mentioned on this list a few days ago, he is trying to  
gather those fixes to make a 3.8.1 release. You should coordinate  
with him to avoid double work.

> (I wonder if they have kind of private 3.8.1 for all related  
> projects like
> Tweak, Sophie, Croquet, Impara... it would be quite strange not to
> share to work of bugfixing basic stuff)

I've been using 3.8 as is. Occasional bugs and fixes I have posted to  
Mantis and/or Squeak-Dev.

We have a packaged version of 3.8, which Andreas published and 3.9  
was built from. Almost nothing changed in that packaged version until  
now, the repository has been publicly accessible the whole time.

I'm pretty sure nobody is secretly fixing bugs behind your back ;-)

- Bert -

Yeeeesssssssssssssssssssss
We are not idling :), but will really pay attention to all the stuff  
mike will send us.

ouf, our paranaio level can decresase now. :)

Stef

On 1/25/06, Peace Jerome <[hidden email]> wrote:
> Seeing a traits refactoring would be interesting as an
> experiment and risky to the development enviornment. I
> would like to have a good refactored smalltalk version
> to launch a traits refactoring from. The former won't
> slow down the latter it would probably make it easier
> and cleaner.

I agree whole heartedly.  That is one of the major reasons for
refactoring.  Well factored code is much easier to alter.  This will
also provide a great opportunity to get even more test into the
system.

> The crews to do the first refactoring and the second
> traits refactoring should be different. And I don't
> think the feature lovers of 3.9 should head the effort
> to just reorganize things. We have to find someone
> with the enthusiasm for that task.
>
> Ditto for the traits refactoring though I can hear the
> energy for that in the list already.

Yeah, there will be more excitement about the Traits work.  It's new
and "sexy."  However, the refactorings are more important IMO.  We
should include Traits and let people get a feel for how to use it in
the wild before it is used by the core classes.  That may just be my
own fear due to lack of understanding of or experience with Traits.

- Wilkes

On 1/25/06, Wilkes Joiner <[hidden email]> wrote:
> Yeah, there will be more excitement about the Traits work.  It's new
> and "sexy."  However, the refactorings are more important IMO.

Is is not an either/or. Traits is probably one of the most powerful
refactoring tools that has been added to the image. Look at the
original work, where (IIRC) Collections were refactored.

For the time being, until we find out what patterns make a priori
sense with Traits, I only see traits being introduce after the fact:
you're looking at some class structure that's getting ugly, then you
refactor stuff into one or more trants, and continue. If we don't
refactor existing code (especially code that is shouting, loudly,
"refactor me with Traits!"), we'll never learn the patterns.

> Wilkes Joiner
> Sent: Wednesday, January 25, 2006 10:27 AM
>
> [snip] We
> should include Traits and let people get a feel for how to use it in
> the wild before it is used by the core classes.  That may just be my
> own fear due to lack of understanding of or experience with Traits.
>

I agree with this but for purely selfish reasons.  I would like to play with
and lean Traits, so that I can participate in the refactoring of the
collection classes.

Ron Teitelbaum

here is what I suggest,

instead of refactoring, why do you try to come up with a new
collection libraries. This can be quite fun to start from a white page
and avoid to have Dictionary inheriting from Set.

  I will the idea of andreas about parallel dev when it
make sense. I also think that if we look at collection they work
quite well from a client point of view. This is why I'm not really  
excited
to change them. There other parts of the system that I would like to
see cleaner.

Stef

On 1/25/06, stéphane ducasse <[hidden email]> wrote:
>   I will the idea of andreas about parallel dev when it
> make sense. I also think that if we look at collection they work
> quite well from a client point of view.

Depends on your point of view. As soon as you want to extend the
collection hierarchy, you're deep into code duplication land. Look at
e.g. MagmaCollection (Kolibri has a DGVCollection and one or two other
places where the whole basic collection protocol has been duplicated).
>From that point of view, the current collection hierarchy sucks big
time.

On 25 janv. 06, at 17:21, Cees De Groot wrote:

Sure I'm just a stupid user of collection. I agree as an extender.

On 1/25/06, Cees De Groot <[hidden email]> wrote:
> On 1/25/06, Wilkes Joiner <[hidden email]> wrote:
> > Yeah, there will be more excitement about the Traits work.  It's new
> > and "sexy."  However, the refactorings are more important IMO.
>
> Is is not an either/or. Traits is probably one of the most powerful
> refactoring tools that has been added to the image. Look at the
> original work, where (IIRC) Collections were refactored.

It's been about year since I've looked at Traits, and I really need to
look at it again before expressing my opinions.

> For the time being, until we find out what patterns make a priori
> sense with Traits, I only see traits being introduce after the fact:
> you're looking at some class structure that's getting ugly, then you
> refactor stuff into one or more trants, and continue. If we don't
> refactor existing code (especially code that is shouting, loudly,
> "refactor me with Traits!"), we'll never learn the patterns.

I don't disagree with any of the above.  I'm just concerned about
pushing our learning experiences into the main image.  I may be too
cautious about this.

- Wilkes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cees De Groot a écrit :
Lukas had to reimplement some methods of the Collection hierarchie for
his decorations for example. Traits would have been useful to avoid
duplication.

- --
Damien Cassou
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD2ket3hhx1vOEX5sRAqGPAJ9MDbTgIHDVE1oVrMnfHrquRpnBpgCgpme/
bXiXfIhTwQPtPDUlsH9dpgE=
=wbZU
-----END PGP SIGNATURE-----