[squeak-dev] Squeak vision

Ian Trudel wrote: The proposed vision is for squeak to be a kernel with loadable packages
for different needs.
So the usability is in the hands of the person who chooses to build a
usable full image from the pieces available.

That person could be you.

Otherwise just load the dev image from Damien which has all this loaded
already.

Keith

> Whoever cares about Morphic.
>
> As I explained before, Etoys development happened outside of squeak.org
> since 3.9. And even if we start fixing it now it will take quite some
> time before it is fully usable again.

Exactly the point, Etoys already forked.  Stop holding onto an old
rotting version in Squeak that isn't used, take it out, it doesn't
belong there.  People who want eToys have their fork where it is maintained.

> Besides, it's not like all other subsystems have active maintainers, so
> there's no point in singling out Etoys.

It's an example, so yes, there is a point.  Any system that isn't part
of the core that all apps need, especially those that aren't maintained,
and especially those that make a mess of things when people are trying
to improve the core, should be removed.

>> Ditto, why is so hard for some to see that eToys isn't Squeak, it's an
>> app build on Squeak?
>
> Because it's not. Wish it was, but it isn't. I guess you never actually
> understood the code. Nobody can even draw a clear line between what is
> Etoys and what is not. And no, the system categories mentioning "Etoys"
> are not it by far.

But it should be.  Yes, it isn't, but they already forked, so it doesn't
matter anymore. eToys doesn't belong in Squeak anymore, it's just
rotting there.

>> It doesn't need to be in Squeak at all, any version.  What it needs is
>> to be able to be loaded into Squeak like any other application.  
>> There's just no justification for it being in the core image; none.
>
> You're welcome to help make it so. It's just not as easy as ripping it out.

Pharo's doing it, Juan did it.  It can be done.

> I think the discussion so far showed once more that there is wide
> agreement for Etoys having a major place in the squeak.org community.
> But the details of how it should be maintained are not well understood.

I think it's shown there is wide disagreement and since eToys already
forked I can't understand the reasoning behind the "let's keep it" side
expect to say they're just resistant to all change.

Honestly, I don't care anymore.  eToys was just brought up as an example
to point out the difference between the "let's make progress" side vs
the "no change monolithic image" side.  I already left Squeak in peace,
I'll be using Pharo and anyone I introduce to Smalltalk will never see
Squeak because they'll start with Pharo.  I'm tired of apologizing for
Squeak being a kids toy.

Ramon Leon
http://onsmalltalk.com

On 2-Jul-09, at 2:49 PM, Ramon Leon wrote:

> Exactly the point, Etoys already forked.  Stop holding onto an old  
> rotting version in Squeak that isn't used, take it out, it doesn't  
> belong there. People who want eToys have their fork where it is  
> maintained.

I think this is one of the key issues in the wider Squeak community  
right now, made all the more difficult because the Etoys team has been  
completely silent on the issue. It's clear that Etoys can be excised  
from Squeak - it's been done a few times already. It's much more  
difficult to separate out a working Etoys package that can be loaded  
into a base image, particularly since the people that would be best  
able to do that are busy with other things. But even if we put in the  
effort and managed to create a loadable Etoys package, it's not clear  
that it would ever get used.

So how about it, Etoys developers? Are you at all interested in  
synchronizing with Squeak at some point in the future? If so, how do  
you imagine it could be accomplished? Is there value in the Etoys code  
that's part of Squeak 3.10? Would you be interested in having a  
cleanly defined Etoys package?

I'm not asking for promises, here, just opinions. Even something vague  
like "Syncronizing would be nice, but we have other priorities" or  
"We're planning to sync, but we've got a deadline just now, please  
bear with us" would make this debate much more productive.

Colin

Ramon Leon wrote:
> Exactly the point, Etoys already forked.  Stop holding onto an old
> rotting version in Squeak that isn't used, take it out, it doesn't
> belong there.  People who want eToys have their fork where it is
> maintained.

s/Etoys/Traits ?

Sorry, couldn't resist.
   - Andreas

2009/7/3 Andreas Raab <[hidden email]>:
> Ramon Leon wrote:
>>
>> Exactly the point, Etoys already forked.  Stop holding onto an old rotting
>> version in Squeak that isn't used, take it out, it doesn't belong there.
>>  People who want eToys have their fork where it is maintained.
>
> s/Etoys/Traits ?
>
> Sorry, couldn't resist.

Traits is part of kernel , its not an application.
And besides it can be unloaded (not sure if there a loader made for it).
Can't resist too :)

>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

Hello Ramon,

RL> Honestly, I don't care anymore.  eToys was just brought up as an example
RL> to point out the difference between the "let's make progress" side vs
RL> the "no change monolithic image" side.  I already left Squeak in peace,
RL> I'll be using Pharo and anyone I introduce to Smalltalk will never see
RL> Squeak because they'll start with Pharo.

if that's true then you might as well stop arguing. It really doesn't
help a discussion taking a strong position and then telling people you
don't care about the subject (Squeak) anymore.


Best regards,

Herbert                            mailto:[hidden email]

Not true, the discussion started trying to figure out how to pull
Pharo improvements back in; that makes it of interest to me.   Pharo
has it's act together, it'd be nice to see Squeak do the same.  It's
too small a community to be so fragmented over nonsense.

Secondly, I'm not taking a strong position so much as a logical one.
I'm engaging more out curiosity about what could be the possible
argument against removing it.  eToys forked, no one has yet made a
reasonable case for keeping the old unmaintained version in Squeak
when so many of the people who ended up forking wanted it removed.
The people who really use eToys don't use Squeak.  Several forks
immediately gutted it out to clean up Morphic, something the Squeak
community wouldn't let them do, an overall attitude that contributes
to such fragmentation of effort.  So I'm curious why the Squeak
community seems to prefer to drive people away and fork rather than
allow some messy rotting unmaintained code to be removed.

Thirdly, it's still a lively discussion about something Smalltalk
related, which is more than enough to make it of interest to me since
seeing any interest at all in Smalltalk is pretty rare, and I do
rather enjoy blathering on about Smalltalk.

Ramon Leon
http://onsmalltalk.com

>> Exactly the point, Etoys already forked.  Stop holding onto an old rotting
>> version in Squeak that isn't used, take it out, it doesn't belong there.
>>  People who want eToys have their fork where it is maintained.
>
> s/Etoys/Traits ?
>
> Sorry, couldn't resist.
>  - Andreas

I don't use them either, didn't work well enough with the tools last
time I tried.

Ramon Leon
http://onsmalltalk.com

On Wed, 01 Jul 2009 03:45:42 -0700, Colin Putney wrote:
> This isn't a new vision, of course, we've supposedly being trying to
> achieve this for a number of years.

FWIW: +1 (for the whole article ;-))

Colin Putney schrieb:
>
> I'm not asking for promises, here, just opinions. Even something vague
> like "Syncronizing would be nice, but we have other priorities" or
> "We're planning to sync, but we've got a deadline just now, please
> bear with us" would make this debate much more productive.
Colin, I'm not a developer, so I cannot answer your previous questions
thoroughly. But as the Director of Education from Squeakland Foundation
I tell you that we would be happy to sync with Squeak again! As I
pointed out in a previous mail, I appreciate the possibility to not let
the learning stop at Etoys level.
To make this happen we need all the help we can get from the community.

Rita
>
> Colin
>

Le mercredi 01 juillet 2009 à 22:50 -0300, Juan Vuletich a écrit :
 
> Not at all. It means literally:
> - It would be great to have Etoys as a package on top of Squeak (as Ian
> says). (That's exactly what I tried to do when I was the Morphic Team
> leader 4 or 5 years ago, btw.) However, saying that and not being able
> to get it done is useless.


Spending the effort on a new framework à-la Etoys could be easier.
Also one could note that Etoys has been quite unsuccessful for large
acceptance in school. Educators here don't like it, they found it too
complicate and unwise to guide the user. I don't know why, but comparing
to how Scratch dealt with building script could give a few hints. Not to
mention the quality of the UI.

In France, Scratch is now cited as a one (preferred) tool to introduce
algorithme in senior high school, Etoys is just unvisible.

Hilaire

As both an educator and a developer my personal feeling on Etoys and
Squeak is some degree of frustration when it come to ship third party
extension for educative use. Obviously I am thinking about DrGeoII.

The state of the art regarding the loading of external Smalltalk
software within Etoys (and Squeak) is for now unacceptable (in term of
user acceptability). The net result is high difficulty to propose
loadable extension then frustration from the developer, then poor
implication of the later one.

All in all, my feeling is that if your participating to the core you are
in, otherwise if you are developing third party extension you are out. I
don't think it is a proper way to build a community.

My personal hope is Pharo will address that in the future (without
mentioning the ability to build a proper user interface), but sadly I
will miss Etoys.

Hilaire

Hello Ramon,

>> RL> Honestly, I don't care anymore.  eToys was just brought up as an example
...
>> RL> I'll be using Pharo and anyone I introduce to Smalltalk will never see
>> RL> Squeak because they'll start with Pharo.
>>
>> if that's true then you might as well stop arguing. It really doesn't
>> help a discussion taking a strong position and then telling people you
>> don't care about the subject (Squeak) anymore.

RL> Not true, the discussion started trying to figure out how to pull
RL> Pharo improvements back in; that makes it of interest to me.  Pharo

RL> Secondly, I'm not taking a strong position so much as a logical one.
RL> I'm engaging more out curiosity about what could be the possible
RL> argument against removing it.

it was not about your strong (pointed, opinionated?) position but
about your declaring you don't care anymore.

RL> Thirdly, it's still a lively discussion about something Smalltalk
RL> related, which is more than enough to make it of interest to me since
RL> seeing any interest at all in Smalltalk is pretty rare, and I do
RL> rather enjoy blathering on about Smalltalk.

I did not want to express you should not take part in the discussion.


Best regards,

Herbert                            mailto:[hidden email]

Hello,

2009/7/3 Nikolay Suslov <[hidden email]>:
> Hello,

Hello Nikolay!

> "The quality of the UI" ? )
> Just to mention, the that Scratch has made a great step backward in UI
> (comparable to Squeak/Etoys).
> It disallows the use of Halos!

Just a quick note. Most deployed applications using Squeak disable
programmer facilities and halos. Basically, it's normal to not have
halos in an end-user project/product that is not oriented toward
programmers.

Regards,
Ian.

--
http://mecenia.blogspot.com/

On 03.07.2009, at 01:44, Colin Putney wrote:

Err, counting the number of mails I sent on the subject just in the  
last few days can hardly be called "completely silent," can it?

> It's clear that Etoys can be excised from Squeak - it's been done a  
> few times already. It's much more difficult to separate out a  
> working Etoys package that can be loaded into a base image,  
> particularly since the people that would be best able to do that are  
> busy with other things. But even if we put in the effort and managed  
> to create a loadable Etoys package, it's not clear that it would  
> ever get used.

Once it reaches a state as stable as the current Squeakland release,  
yes, definitely.

> So how about it, Etoys developers? Are you at all interested in  
> synchronizing with Squeak at some point in the future?

Yes.

> If so, how do you imagine it could be accomplished?

Figuring that out is precisely why I started this thread. I don't  
exactly know.

> Is there value in the Etoys code that's part of Squeak 3.10?

There might well be a few fixes that have not made it over into the  
Squeakland release.

> Would you be interested in having a cleanly defined Etoys package?

Yes, because that's the chosen unit of work in this community.

> I'm not asking for promises, here, just opinions. Even something  
> vague like "Syncronizing would be nice, but we have other  
> priorities" or "We're planning to sync, but we've got a deadline  
> just now, please bear with us" would make this debate much more  
> productive.


"we'd love to sync with squeak.org, but we're only a handful of  
volunteers so far, so we need help"

Maybe I need to restate the current affairs:

Etoys development was funded for over 2 years by VPRI, to create a  
version for the One Laptop Per Child project, running in Linux under  
Sugar. That Etoys version has also been adapted to work on regular  
machines, this is the new release at Squeakland.org.

Now the keys have been passed on to the Squeakland Foundation, and  
development is done solely by volunteers. The Foundation is seeking  
funds, but even if they were successful in raising money it would not  
go primarily to sponsoring developers but on creating documentation,  
curricula, etc. Unless it's Big Money of course ;)

So Etoys is considered stable for now, the volunteer developers are  
mainly busy with bug fixing. But future development would be much more  
effective in close cooperation with squeak.org.

And clearly, both sides benefit. A lot of improvements in the VM were  
driven by Etoys needs (I maintained an "olpc" VM branch for a while  
that has now been folded back into the trunk). Localization has been  
advanced considerably. Parts that were easily separable from Etoys  
have actually been made available to Squeak in general (e.g., D-Bus  
support for Linux, the GStreamer media framework, Cairo/Pango  
rendering, as well as occasional fixes we posted to Mantis).  
Conversely Etoys would benefit from improvements in Squeak that have  
been done since development forked, so it looks like a clear win-win  
to me.

Besides, Squeak and Etoys are still synonymous to many people (as you  
can see from a lot of postings on the newbies list) so one major  
source of confusion would dry up. Or maybe not ;)

- Bert -

Bert Freudenberg a écrit :


> The Scratch team just made different design choices, they are not
> universally better or worse. I admire the clarity and ease-of-use of

Obviously, but the net consequence is different user acceptability, and
as far as user acceptability means something, Scratch is better in that
field.

Nevertheless, I share your feel about the Etoys way of doing things
which I largely prefer to the most constrained way of doing with
Scratch. But for average user, the constrained way of Scratch seems to
be better, probably the user stress is lower thanks to more guided
interface.

If we want user to spend resources (time) learning and using Etoys, the
user should see an important benefice. I think Etoys should come with
more advanced artifacts to build really complex things very simply (aka
DrGeo for geometry, kedema for particle simulation, same with
electricity, and many more). Such complex artifacts could interact to
each other thanks to the Etoys scripting, then yes the user could see
really neat benefice worth the energy learning Etoys.

The first step in this direction could be a fast bytecode package
loader, without the need to compile Smalltalk code.

Hilaire

At Thu, 02 Jul 2009 20:36:57 +0200,
Michael Rueger wrote:
  Heh.  For those who are wondering how my Japanenglish works, I
didn't mean "a pirated game", but a game where the players control
pirate ships.

> >   - Sophie
>
> Sophie is OpenSource (new BSD) (Impara worked on it as part of a funded
> project).

  Right.  I should've made it clear that.

-- Yoshiki

On 03.07.2009, at 18:01, Hilaire Fernandes wrote:

Agreed. Maybe a design wizard could come up with an interface both  
powerful and simple, but so far it looks like the two are in constant  
fight.


Indeed. Perhaps you remember the discussions we had about  
ImageSegments that loaded classes complete with CompiledMethods? Which  
is way way faster than compiling code, and could not only be used to  
load squeak apps on top of a fixed image like for Dr Geo on Etoys, but  
could also lead to blazingly fast updates, or to very efficient field  
patches of deployed software. Maybe bringing this idea up in a  
separate thread here on squeak-dev would get some developer intrigued  
- I for one do find this a fascinating project.

- Bert -