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
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 -
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.
Yeeeesssssssssssssssssssss We are not idling :), but will really pay attention to all the stuff mike will send us.
(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 ;-)
ouf, our paranaio level can decresase now. :)
Stef
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
On 1/25/06, Peace Jerome peace_the_dreamer@yahoo.com 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 wilkesjoiner@gmail.com 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.
On 1/25/06, Cees De Groot cdegroot@gmail.com wrote:
On 1/25/06, Wilkes Joiner wilkesjoiner@gmail.com 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
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 ducasse@iam.unibe.ch 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:
On 1/25/06, stéphane ducasse ducasse@iam.unibe.ch 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.
Sure I'm just a stupid user of collection. I agree as an extender.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Cees De Groot a écrit :
On 1/25/06, stéphane ducasse ducasse@iam.unibe.ch 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.
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
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Cees De Groot -
Damien Cassou -
Marcus Denker -
Peace Jerome -
Ron Teitelbaum -
stéphane ducasse -
Wilkes Joiner