Smalltalk › Squeak › Squeak - Dev

Smalltalk Reloaded Was:Re: Removing Etoys (was Re: A process proposal for 3.10)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

Mark Miller

Smalltalk Reloaded Was:Re: Removing Etoys (was Re: A process proposal for 3.10)

Laurence Rozier wrote:

> Smalltalk is much more than a programming language, it is a complete environment that represents the true philosophy of

> open, user-driven computing. Smalltalk provides an environment that makes programming fun for young and old, and it
> shields us from the plethora of APIs and technology our industry calls progress. It respects the disparate cultures of
> business programmers, students and systems programmers. Most of all it encourages "we" programming as opposed to "me"
> programming.
>
> Travels With Smalltalk<http://www.mojowire.com/TravelsWithSmalltalk/DaveThomas-TravelsWithSmalltalk.htm>
>
> In the early 90's, before Java Smalltalk had a thriving prosperous community. IBM, ParcPlace and Digitalk offerings were
> gaining momentum in large corporations where C++ was failing miserably in enterprise projects. Many(m ost?) new major
> projects were choosing Smalltalk(Object-Oriented Information Systems by David Taylor documents this). Small and
> independent developers could learn from the affordable Smalltalk/V family and with the advent of Widgets/WindowBuilder
> could deploy solutions with it. Books were being written. If you were a knowledgeable Smalltalker, you could make a
> good living doing it. Then lots of smart people couldn't figure out a reasonable, mutually beneficial way forward. It
> really doesn't matter who you think was "more" to blame, the vacuum that was filled by Java wasn't created by
> anti-Smalltalkers, it came from the implosions within the community.

I'm a new Squeaker. I was introduced to the Smalltalk language in the early 1990s and enjoyed it a lot. It was one of the most enjoyable languages I had ever used, and I didn't even have a GUI to play around with :). Unfortunately the introduction was short, and I moved on from there. I recently dug out the old Smalltalk code I wrote and remembered that experience with fondness. I also found some of Alan Kay's presentations on Squeak and eToys online that are a few years old, and I was enthralled by them. Since then I've been rediscovering Smalltalk via. Squeak. I've used eToys a little bit, just to get familiar with the environment. I plan on using it some more in the future, along with Alice. The initial hook for me with Squeak was eToys. Part of the draw was its similarity to the original features of Smalltalk-80. What drew me to Squeak even more was Seaside, having had some professional experience with web app. development.

Laurence-

It was wonderful reading your retrospective on what happened with Smalltalk years ago. I can corrolate what you describe with my own superficial experience. I was in college during the time period you talk about. That was where I first learned Smalltalk. What I'll describe is my experience as a U.S. citizen. During the summers I'd look for internships in my state, and in the early 1990s it was common for me to see employers looking for people with Smalltalk skills--typically 3-5 years worth. They wanted experts. By the time I graduated from college in 1993, all of those Smalltalk want ads were gone. C and C++ had been emerging as in-demand languages over the same time period. Eventually they came to dominate the want ads. I was kind of disappointed. I was looking forward to the possibility of finding work programming in Smalltalk. It wasn't to be, at least not then. I had fun for a while programming in C, then Java, then C++, and more recently C# in .Net, but after working in these languages for a while I always felt as though something was missing. When I was in the public schools I programmed in BASIC and Logo. Programming was simple and fun. Sometimes the problems were hard, but I could never blame that on the language. IMO the Smalltalk language and eToys revive the notion of programming being simple and fun.

I think whoever is in charge of the dev. team needs to be cognizant of the guiding vision for Squeak and insist that the developers of the official distribution stick to it. From listening to Alan Kay's presentations on Squeak, my own sense is it's intended to be approachable, first and foremost, but it has the capability "out of the box" to scale up for more complex tasks. Education seemed to be close to the hearts of Squeak's creators. They wanted it to be usable by children, educators, on up to professional developers. So I don't see a problem that needs fixing with the way Squeak is presently configured in the general sense, with a GUI, flaps, as well as code browsers, a debugger, etc. What I see with the discussion about trying to modularize Squeak is a kind of traditional computer science/software engineering mindset that "it's better to have things modularized", so there's a natural gravitational pull in that direction in the development community. As I've said before o n other forums, integration has its advantages too, particularly for the technology's users. Developers don't like it because it makes their jobs harder. I can sympathize with that. Another example of an integrated technology approach is MS-Windows. It's one reason why it's going to end up taking Microsoft 5 or 6 years to come out with a new version of their OS that's only a modest improvement over what they did before in terms of OS features.

I just know that if eToys were removed in the image that everybody downloads, and I had come along later, it would've been an immediate turn-off to me. Maybe I still would've pursued it, because Smalltalk is a draw for me to Squeak, but I would've seen it as a disappointment, particularly since it's such a defining feature. It draws inspiration from what was implemented in the original Smalltalk system developed at Xerox PARC. The inclusion of eToys in Squeak was not an accident. It should not be viewed as an anomoly, an obstacle that can simply be removed from the main image. It's a crucial feature in something that Squeak was meant to be: a platform that could be used to manipulate all forms of media: graphics, text, and sound, where everything is an object.

Squeak has already turned out to be a disappointment to some with an educational focus, apparently. I've brought this up before (elsewhere) that I had a conversation with Mark Guzdial recently, who wrote a couple books on Squeak several years ago, and is a professor in the College of Computing at the Georgia Institute of Technology. It sounded like he's long since given up on Squeak, due to multimedia features that used to work being broken in more recent versions. I have the feeling he's not alone in that sentiment. From talking to him it sounded like Squeak had already started to fork a while ago--with some features educators liked working in earlier versions, but not in later ones. It's a shame to see this because I think Squeak would make a great educational computing platform. The Squeak community should be promoting and supporting it in education, not driving people away.

As I've read through the arguments about how to go about improving Morphic, and splitting it off from eToys, it sounds more like the main barrier to doing that is the time involved, not that it's impossible to do from an engineering standpoint. I find it hard to believe that, assuming for the sake of argument the developers had all the time in the world to work on it, they couldn't rewrite both so that Morphic could be independent of eToys. Maybe there would be some "emulation" involved to make everything work, but anything is possible given enough effort and time. I understand what I've just said is theoretical, for all practical purposes. I've gotten the sense that most/all people involved in the development effort are volunteers. I would encourage people to think more about how to enhance what Squeak is and is meant to be, rather than thinking expediently about how to accomplish an engineering goal. In a past discussion on "What is Squeak?" I found it a bit shocking th at a couple people viewed Squeak as just "a VM, a compiler, and an API". It's more than that, and I hope that eventually everybody will come to realize this.

It seems to me there are different levels of Squeakers, and the development community should understand that this is no accident. It's the way the original designers of Squeak intended it to be. So there are people who work at the eToys level. They do some scripting, but they aren't digging deep into Squeak (at the Smalltalk level), and don't necessarily want to. Then there are the people who really like working at the system level. They're the ones who see Squeak at the technical level, and they see what's really going on behind the scenes. They've stated quite plainly that some of what's there is ugly, and they'd love to see it improved. Such is the life of the developer.

I think Squeak is unique among open source projects, because it attracts both people who have a computer use focus, and those who have a software development focus. Linux is kind of this way too, though I think it has more appeal to system administrators and hackers (maybe this is a misimpression on my part).

My own view is that if there's a real desire to fork the implementation, to pursue the technical advancement of the platform, then people should be free to do that, but whatever they do should probably not be called Squeak, just so people don't get confused. If this were to happen they should form their own working group to pursue it. They could call it "OpenSmalltalk", if they want, something like that. It's kind of been done before. Just look at Croquet. I personally would not see it as a negative event in the community if this were to happen. If people feel held back by Squeak, they can be liberated from those perceived limitations and free to pursue their goals. If the fork advances well, maybe Squeak could draw some ideas from the forked project and incorporate them into Squeak at a later time. Everybody could gain something.

Anyway, that's my 2 cents.

---Mark

Guy Bloomfield

Re: Smalltalk Reloaded Was:Re: Removing Etoys (was Re: A process proposal for 3.10)

Dear All,
I am a very basic programmer and in awe of those who produce Squeak
and Seaside etc. (On the other hand if your baby is sick...).

It seems pretty simple to me.

1, A technical issue - can E-toys +/- Mprphic be loadable unloadable?
Obviously can if someone wants to.

2. A functional issue - The ideal Squeak would have Etoys Morphic in
the image and these could be unloaded by the experienced programmer
who wants to "Run light without overbyte" whereas the neophyte can
enjoy them out of the box

3, It is summer down here in New Zealand

Guy

On 28/10/2006, at 6:44 PM, [hidden email] wrote:

> Laurence Rozier wrote:
> > Smalltalk is much more than a programming language, it is a
> complete environment that represents the true philosophy of
> > open, user-driven computing. Smalltalk provides an environment
> that makes programming fun for young and old, and it
> > shields us from the plethora of APIs and technology our industry
> calls progress. It respects the disparate cultures of
> > business programmers, students and systems programmers. Most of
> all it encourages "we" programming as opposed to "me"
> > programming.
> >
> > Travels With Smalltalk<http://www.mojowire.com/
> TravelsWithSmalltalk/DaveThomas-TravelsWithSmalltalk.htm>
> >
> > In the early 90's, before Java Smalltalk had a thriving
> prosperous community. IBM, ParcPlace and Digitalk offerings were
> > gaining momentum in large corporations where C++ was failing
> miserably in enterprise projects. Many(m ost?) new major
> > projects were choosing Smalltalk(Object-Oriented Information
> Systems by David Taylor documents this). Small and
> > independent developers could learn from the affordable Smalltalk/
> V family and with the advent of Widgets/WindowBuilder
> > could deploy solutions with it. Books were being written. If you
> were a knowledgeable Smalltalker, you could make a
> > good living doing it. Then lots of smart people couldn't figure
> out a reasonable, mutually beneficial way forward. It
> > really doesn't matter who you think was "more" to blame, the
> vacuum that was filled by Java wasn't created by
> > anti-Smalltalkers, it came from the implosions within the community.
>
> I'm a new Squeaker. I was introduced to the Smalltalk language in
> the early 1990s and enjoyed it a lot. It was one of the most
> enjoyable languages I had ever used, and I didn't even have a GUI
> to play around with :). Unfortunately the introduction was short,
> and I moved on from there. I recently dug out the old Smalltalk
> code I wrote and remembered that experience with fondness. I also
> found some of Alan Kay's presentations on Squeak and eToys online
> that are a few years old, and I was enthralled by them. Since then
> I've been rediscovering Smalltalk via. Squeak. I've used eToys a
> little bit, just to get familiar with the environment. I plan on
> using it some more in the future, along with Alice. The initial
> hook for me with Squeak was eToys. Part of the draw was its
> similarity to the original features of Smalltalk-80. What drew me
> to Squeak even more was Seaside, having had some professional
> experience with web app. development.
>
> Laurence-
>
> It was wonderful reading your retrospective on what happened with
> Smalltalk years ago. I can corrolate what you describe with my own
> superficial experience. I was in college during the time period you
> talk about. That was where I first learned Smalltalk. What I'll
> describe is my experience as a U.S. citizen. During the summers I'd
> look for internships in my state, and in the early 1990s it was
> common for me to see employers looking for people with Smalltalk
> skills--typically 3-5 years worth. They wanted experts. By the time
> I graduated from college in 1993, all of those Smalltalk want ads
> were gone. C and C++ had been emerging as in-demand languages over
> the same time period. Eventually they came to dominate the want
> ads. I was kind of disappointed. I was looking forward to the
> possibility of finding work programming in Smalltalk. It wasn't to
> be, at least not then. I had fun for a while programming in C, then
> Java, then C++, and more recently C# in .Net, but after worki ng in
> these languages for a while I always felt as though something was
> missing. When I was in the public schools I programmed in BASIC and
> Logo. Programming was simple and fun. Sometimes the problems were
> hard, but I could never blame that on the language. IMO the
> Smalltalk language and eToys revive the notion of programming being
> simple and fun.
>
> I think whoever is in charge of the dev. team needs to be cognizant
> of the guiding vision for Squeak and insist that the developers of
> the official distribution stick to it. From listening to Alan Kay's
> presentations on Squeak, my own sense is it's intended to be
> approachable, first and foremost, but it has the capability "out of
> the box" to scale up for more complex tasks. Education seemed to be
> close to the hearts of Squeak's creators. They wanted it to be
> usable by children, educators, on up to professional developers. So
> I don't see a problem that needs fixing with the way Squeak is
> presently configured in the general sense, with a GUI, flaps, as
> well as code browsers, a debugger, etc. What I see with the
> discussion about trying to modularize Squeak is a kind of
> traditional computer science/software engineering mindset that
> "it's better to have things modularized", so there's a natural
> gravitational pull in that direction in the development community.
> As I've said be fore o n other forums, integration has its
> advantages too, particularly for the technology's users. Developers
> don't like it because it makes their jobs harder. I can sympathize
> with that. Another example of an integrated technology approach is
> MS-Windows. It's one reason why it's going to end up taking
> Microsoft 5 or 6 years to come out with a new version of their OS
> that's only a modest improvement over what they did before in terms
> of OS features.
>
> I just know that if eToys were removed in the image that everybody
> downloads, and I had come along later, it would've been an
> immediate turn-off to me. Maybe I still would've pursued it,
> because Smalltalk is a draw for me to Squeak, but I would've seen
> it as a disappointment, particularly since it's such a defining
> feature. It draws inspiration from what was implemented in the
> original Smalltalk system developed at Xerox PARC. The inclusion of
> eToys in Squeak was not an accident. It should not be viewed as an
> anomoly, an obstacle that can simply be removed from the main
> image. It's a crucial feature in something that Squeak was meant to
> be: a platform that could be used to manipulate all forms of media:
> graphics, text, and sound, where everything is an object.
>
> Squeak has already turned out to be a disappointment to some with
> an educational focus, apparently. I've brought this up before
> (elsewhere) that I had a conversation with Mark Guzdial recently,
> who wrote a couple books on Squeak several years ago, and is a
> professor in the College of Computing at the Georgia Institute of
> Technology. It sounded like he's long since given up on Squeak, due
> to multimedia features that used to work being broken in more
> recent versions. I have the feeling he's not alone in that
> sentiment. From talking to him it sounded like Squeak had already
> started to fork a while ago--with some features educators liked
> working in earlier versions, but not in later ones. It's a shame to
> see this because I think Squeak would make a great educational
> computing platform. The Squeak community should be promoting and
> supporting it in education, not driving people away.
>
> As I've read through the arguments about how to go about improving
> Morphic, and splitting it off from eToys, it sounds more like the
> main barrier to doing that is the time involved, not that it's
> impossible to do from an engineering standpoint. I find it hard to
> believe that, assuming for the sake of argument the developers had
> all the time in the world to work on it, they couldn't rewrite both
> so that Morphic could be independent of eToys. Maybe there would be
> some "emulation" involved to make everything work, but anything is
> possible given enough effort and time. I understand what I've just
> said is theoretical, for all practical purposes. I've gotten the
> sense that most/all people involved in the development effort are
> volunteers. I would encourage people to think more about how to
> enhance what Squeak is and is meant to be, rather than thinking
> expediently about how to accomplish an engineering goal. In a past
> discussion on "What is Squeak?" I found it a bit shock ing th at a
> couple people viewed Squeak as just "a VM, a compiler, and an API".
> It's more than that, and I hope that eventually everybody will come
> to realize this.
>
> It seems to me there are different levels of Squeakers, and the
> development community should understand that this is no accident.
> It's the way the original designers of Squeak intended it to be. So
> there are people who work at the eToys level. They do some
> scripting, but they aren't digging deep into Squeak (at the
> Smalltalk level), and don't necessarily want to. Then there are the
> people who really like working at the system level. They're the
> ones who see Squeak at the technical level, and they see what's
> really going on behind the scenes. They've stated quite plainly
> that some of what's there is ugly, and they'd love to see it
> improved. Such is the life of the developer.
>
> I think Squeak is unique among open source projects, because it
> attracts both people who have a computer use focus, and those who
> have a software development focus. Linux is kind of this way too,
> though I think it has more appeal to system administrators and
> hackers (maybe this is a misimpression on my part).
>
> My own view is that if there's a real desire to fork the
> implementation, to pursue the technical advancement of the
> platform, then people should be free to do that, but whatever they
> do should probably not be called Squeak, just so people don't get
> confused. If this were to happen they should form their own working
> group to pursue it. They could call it "OpenSmalltalk", if they
> want, something like that. It's kind of been done before. Just look
> at Croquet. I personally would not see it as a negative event in
> the community if this were to happen. If people feel held back by
> Squeak, they can be liberated from those perceived limitations and
> free to pursue their goals. If the fork advances well, maybe Squeak
> could draw some ideas from the forked project and incorporate them
> into Squeak at a later time. Everybody could gain something.
>
> Anyway, that's my 2 cents.
>
> ---Mark
>
>

tblanchard

Re: Smalltalk Reloaded Was:Re: Removing Etoys (was Re: A process proposal for 3.10)

In reply to this post by Mark Miller

The thing you are missing is that no one is in charge of the dev team. The dev team is you, me, and anybody else with time and inclination to build and release software.

Furthermore, there is no "one true vision". We all have visions and are trying to realize them. At the end of the day - code talks. You like eToys? Believe it should live in Squeak forever? Put in the time to clean it up and make it reloadable. Nobody is stopping you. We would all like that. But everybody has his own itch to scratch and finite resources.

The reason people are considering removing eToys is that it made Morphic too complicated and brittle. It slows us down the way it is. It is why things keep getting broken. It wasn't built on top of Morphic - it was hacked into it.

Feel free to put in the time. I think the best approach is to hack it out - clean up Morphic, and then reimplement it on top of a clean Morphic in an architecturally sound way (assuming somebody wants it badly enough to put in the effort).

There is also a completely new UI framework called Tweak that might replace Morphic - and has an implementation of eToys being built on top of it. Which kind of implies that Morphic is an interim solution anyhow and we might as well do the expedient thing.

This is all just my opinion. I could be wrong.

-Todd Blanchard

On Oct 27, 2006, at 10:44 PM, [hidden email] wrote:

I think whoever is in charge of the dev. team needs to be cognizant of the guiding vision for Squeak and insist that the developers of the official distribution stick to it.

Mark Miller

Re: Smalltalk Reloaded Was:Re: Removing Etoys (was Re: A process proposal for 3.10)

In reply to this post by Mark Miller

Just an observation but you sound kind of jaded.

Re: no one is in charge of the dev. team

So you on your own can decide to release the main image of Squeak for everyone else to download? You're not making a lot of sense here. Who decides what goes into the main image? Who decides when it's in beta, and when it's ready for final release? To hear you talk no one is in charge of any of this. Sounds pretty chaotic to me and not very realistic in terms of managing a credible project.

Even though some object to the notion, most of the open source projects I've heard about that are successful have "benevolent dictators" who decide what goes into a release and what doesn't. They take a lot of input, of course, but ultimately one or a few people make the decisions.

Re: code talks

Yeah, I'm beginning to see that. It sounds like the problem is the users who don't want to take the time to dig into the internals don't have a voice at all in your scheme of things. If the developers don't see a use for something in their own projects, no problem. You can just take it out of the main image that everyone downloads, and the users who depend on what you took out can just go take a hike. If this is the prevailing attitude it's just going to turn Squeak into yet another dev. tool that no one besides developers will have an interest in. So much for Smalltalk representing a new computing platform, right? Instead of just serving your own interests, why not take the time to do what it takes to maintain the vision that is there and improve upon it? I'm not speaking just of you when I say this, but of the Squeak developers generally. If it takes a long time to refactor eToys, why not take the time to do it, however long it takes? What's the rush to get out the next release? That's what I was kind of getting at in my previous post. Why not take the time to do it right? If it means it takes a few years, then it takes a few years.

I understand I could contribute to this, but if none of the other Squeak system developers are interested in the same vision, it's kind of a disincentive to invest the time, because it'll mean I'm carrying the load myself. Plus it may not be appreciated for what it is and get tossed out. This is what I'm alluding to with the "overall vision" thing. I am interested in the overall vision of Squeak as it exists persisting, even though I may not use some of the features. If there's no guiding vision, how is anyone going to have an idea if a contribution to the main image is going to be accepted or not? What's the incentive to make a contribution that's altruistic? In the situation you're talking about, as I see it, it's everyone for themselves. People will just contribute things that they have a personal invested interest in, because at least if it's not accepted, it'll be useful to themselves. It kind of sounds like that's the way things have been go ing. And it takes me full circle back to what I see as the main problem: the users who are not system developers don't have a voice in the process. Basically they're depending on there *being* a guiding vision, because they don't know enough to have control over the internals. They're just depending on what they're used to continuing to work.

I may very well become a contributor in the future. As I've indicated I'm very interested in the platform. I'm learning about Squeak right now, so I don't think my skills would be that useful in terms of refactoring eToys at this point in time. Maybe in the future.

You mentioned Tweak. I went by a web page for it, and it didn't look like there was a lot to it, at least from the screenshots they were showing. Does it have a complete implementation of eToys or just a subset?

Re: eToys was hacked into Morphic. That's the reason things keep breaking.

In the PC world I've sometimes seen system implementations that are "just enough" to run another technology on top of it. It sounds like this is what happened with Morphic--just enough was implemented to run eToys. I wonder what the expectation was? Was this done by design, and the assumption was that if there were improvements to be made, that the UI would just grow organically out of what was already there? Maybe the original developers didn't have a full implementation of Morphic in mind, but rather just wanted to get the development process started, and hoped that others would just build on top of it. Like I said, I'm just learning about it at this point, so I don't know the internals as well as others on here. Again, I wonder if the reason why stuff keeps breaking, is that the developers who are working with it are trying to impose a model on it that is incompatible with the way it was developed earlier. Maybe whoever did it had other intentions in mind and the current crop of developers are not seeing it.

I'm finding it difficult to believe that with the design of Smalltalk being so elegant that something like this would be done sloppily. I guess I'm wondering about the history of how this developed.

Re: This is just my opinion

Alright. So I've expressed mine too. :)

---Mark

-------------- Original message --------------
From: Todd Blanchard <[hidden email]>

The thing you are missing is that no one is in charge of the dev team. The dev team is you, me, and anybody else with time and inclination to build and release software.

Furthermore, there is no "one true vision". We all have visions and are trying to realize them. At the end of the day - code talks. You like eToys? Believe it should live in Squeak forever? Put in the time to clean it up and make it reloadable. Nobody is stopping you. We would all like that. But everybody has his own itch to scratch and finite resources.

The reason people are considering removing eToys is that it made Morphic too complicated and brittle. It slows us down the way it is. It is why things keep getting broken. It wasn't built on top of Morphic - it was hacked into it.

Feel free to put in the time. I think the best approach is to hack it out - clean up Morphic, and then reimplement it on top of a clean Morphic in an architecturally sound way (assuming somebody wants it badly enough to put in the effort).

There is also a completely new UI framework called Tweak that might replace Morphic - and has an implementation of eToys being built on top of it. Which kind of implies that Morphic is an interim solution anyhow and we might as well do the expedient thing.

This is all just my opinion.? I could be wrong.

-Todd Blanchard

On Oct 27, 2006, at 10:44 PM, [hidden email] wrote:

I think whoever is in charge of the dev. team needs to be cognizant of the guiding vision for Squeak and insist that the developers of the official distribution stick to it.

Mark Miller

Re: Smalltalk Reloaded Was:Re: Removing Etoys (was Re: A process proposal for 3.10)

In reply to this post by Mark Miller

Okay. Now I get it.

To quote myself from earlier:

"Re: eToys was hacked into Morphic. That's the reason things keep breaking.

I'm finding it difficult to believe that with the design of Smalltalk being so elegant that something like this would be done sloppily. I guess I'm wondering about the history of how this developed."

I found this from Alan Kay on April 22 in this list:

"Etoys was a demo and a prototype. It is a real tribute to Squeak (and the
team) that it was actually shippable around the world. But it is not a
production system, and it is not scalable to the hundred dollar laptop as
it stands. It needs to be reimplemented, and many parts have to be
improved. We have been doing some of this (and the results are interesting)
but we have to take every avenue to get a scalable version that can be
taken care of by more production like people."

This explains a lot. It sounds like from what he's saying that work was under way then to rework eToys. What I'm unclear on is to what end, since I grabbed this out of the discussion that was going on about the possibility of porting eToys to Python. Anyway, this answered my questions about eToys.

For the edification of others, the post I got this quote from is here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102912.html

---Mark

Jecel Assumpcao Jr

here is a plan! (was: Smalltalk Reloaded)

In reply to this post by Guy Bloomfield

Guy Bloomfield wrote on Sat, 28 Oct 2006 19:30:14 +1300
> 2. A functional issue - The ideal Squeak would have Etoys Morphic in
> the image and these could be unloaded by the experienced programmer
> who wants to "Run light without overbyte" whereas the neophyte can
> enjoy them out of the box

This is a plan that is practical and which I fully support: if we can
unload eToys but not load it back, then let's just include eToys in the
full image that we distribute and allow everyone the one way option of
removing it. I don't mind at all eliminating the Flash logo, the welcome
windows and other stuff every time I begin working with a newly
downloaded image. The fact that I can't get any of these easily back if
I want has never been a problem since I could just start over from a
clean image.

Sure, a reloadable eToys would be even better but I doubt it will
happen.

-- Jecel

Ron Teitelbaum

RE: here is a plan! (was: Smalltalk Reloaded)

+1

Ron Teitelbaum

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Jecel Assumpcao Jr
> Sent: Monday, October 30, 2006 10:48 AM
> To: The general-purpose Squeak developers list
> Subject: here is a plan! (was: Smalltalk Reloaded)
>
> Guy Bloomfield wrote on Sat, 28 Oct 2006 19:30:14 +1300
> > 2. A functional issue - The ideal Squeak would have Etoys Morphic in
> > the image and these could be unloaded by the experienced programmer
> > who wants to "Run light without overbyte" whereas the neophyte can
> > enjoy them out of the box
>
> This is a plan that is practical and which I fully support: if we can
> unload eToys but not load it back, then let's just include eToys in the
> full image that we distribute and allow everyone the one way option of
> removing it. I don't mind at all eliminating the Flash logo, the welcome
> windows and other stuff every time I begin working with a newly
> downloaded image. The fact that I can't get any of these easily back if
> I want has never been a problem since I could just start over from a
> clean image.
>
> Sure, a reloadable eToys would be even better but I doubt it will
> happen.
>
> -- Jecel
>

Klaus D. Witzel

Re: here is a plan! (was: Smalltalk Reloaded)

In reply to this post by Guy Bloomfield

Hi Jecel,

on Mon, 30 Oct 2006 16:48:05 +0100, you wrote:

> Guy Bloomfield wrote on Sat, 28 Oct 2006 19:30:14 +1300
>> 2. A functional issue - The ideal Squeak would have Etoys Morphic in
>> the image and these could be unloaded by the experienced programmer
>> who wants to "Run light without overbyte" whereas the neophyte can
>> enjoy them out of the box
>
> This is a plan that is practical and which I fully support: if we can
> unload eToys but not load it back, then let's just include eToys in the
> full image that we distribute and allow everyone the one way option of
> removing it.

Let me try and reformulate your plan with two set operators (- "minus" and
+ "plus")

Squeak - "Pavel's" (Etoys + Morphic)
+ "Juan's" Morphic
= (Squeak - Etoys)

If there'd be strong support for Pavel *and* for Juan then dreams would
come true.

/Klaus

> I don't mind at all eliminating the Flash logo, the welcome
> windows and other stuff every time I begin working with a newly
> downloaded image. The fact that I can't get any of these easily back if
> I want has never been a problem since I could just start over from a
> clean image.
>
> Sure, a reloadable eToys would be even better but I doubt it will
> happen.
>
> -- Jecel
>
>

Jecel Assumpcao Jr

Re: here is a plan! (was: Smalltalk Reloaded)

Klaus D. Witzel wrote on Mon, 30 Oct 2006 17:58:57 +0100

> > This is a plan that is practical and which I fully support: if we can
> > unload eToys but not load it back, then let's just include eToys in the
> > full image that we distribute and allow everyone the one way option of
> > removing it.
>
> Let me try and reformulate your plan with two set operators (- "minus" and
> + "plus")
>
> Squeak - "Pavel's" (Etoys + Morphic)
> + "Juan's" Morphic
> = (Squeak - Etoys)
>
> If there'd be strong support for Pavel *and* for Juan then dreams would
> come true.

This is a different plan. In fact, in many ways it is the opposite of
Guy's plan I was endorsing.

Juan Vuletich wrote on Wed, 18 Oct 2006 09:11:45 -0300 (ART):
> What I propose can be done. I did it for 3.7. You can download it from
> http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html . I
> believe Pavel did something similar (although I haven't looked at it.

So to express the plan I am talking about in your notation:

Squeak3.10 - Juan's 3.7 work updated for 3.10 = Squeak3.10 - EToys

The difference is that this would be an operation that could be
automated, so that we could distribute "Squeak 3.10 Full" and each
interested person could call up a menu option and generate the EToyless
image as needed. I am supposing that the plan you described would be a
one time thing (since the Morphic being removed and the Morphic being
added back are not the same) . It might be a bit subtle, since I am
perfectly ok with having a "Squeak 3.10 Basic" image that doesn't
include EToys. What I don't want to see happen is a version with no
EToys options at all.

-- Jecel

Juan Vuletich (dc)

Re: here is a plan!

In reply to this post by Guy Bloomfield

Hi Jecel,

Removing eToys implies deleting "eToys awareness" in lots of methods
that would not be deleted. Even several instance variables as in
MorphExtension. I don't know how to offer the user the option for
removing it, let alone keep that option properly maintained in future
Squeak versions.

Cheers,
Juan Vuletich

Jecel Assumpcao Jr escribió:

> Guy Bloomfield wrote on Sat, 28 Oct 2006 19:30:14 +1300
>
>> 2. A functional issue - The ideal Squeak would have Etoys Morphic in
>> the image and these could be unloaded by the experienced programmer
>> who wants to "Run light without overbyte" whereas the neophyte can
>> enjoy them out of the box
>>
>
> This is a plan that is practical and which I fully support: if we can
> unload eToys but not load it back, then let's just include eToys in the
> full image that we distribute and allow everyone the one way option of
> removing it. I don't mind at all eliminating the Flash logo, the welcome
> windows and other stuff every time I begin working with a newly
> downloaded image. The fact that I can't get any of these easily back if
> I want has never been a problem since I could just start over from a
> clean image.
>
> Sure, a reloadable eToys would be even better but I doubt it will
> happen.
>
> -- Jecel
>
>
>

Klaus D. Witzel

Re: here is a plan! (was: Smalltalk Reloaded)

In reply to this post by Klaus D. Witzel

Hi Jecel,

on Mon, 30 Oct 2006 21:46:56 +0100, you wrote:
Klaus wrote:
...
>> Squeak - "Pavel's" (Etoys + Morphic)
>> + "Juan's" Morphic
>> = (Squeak - Etoys)
...
> So to express the plan I am talking about in your notation:
>
> Squeak3.10 - Juan's 3.7 work updated for 3.10 = Squeak3.10 - EToys

Hhm, not that I see any difference on the RHS but, yes: so it is (so it
be).

> The difference is that this would be an operation that could be
> automated, so that we could distribute "Squeak 3.10 Full" and each
> interested person could call up a menu option and generate the EToyless
> image as needed. I am supposing that the plan you described would be a
> one time thing (since the Morphic being removed and the Morphic being
> added back are not the same) .

No, I didn't have a one time operation in mind. I'd leave that (support of
unloading/loading for more than one release) to Pavel and Juan.

And yes, Juan most likely doesn't want the new Morphic be the same as the
old one.

> It might be a bit subtle, since I am
> perfectly ok with having a "Squeak 3.10 Basic" image that doesn't
> include EToys. What I don't want to see happen is a version with no
> EToys options at all.

Since I'm on the neutral side: yes, give choice to the users.

Guy's suggestion is what we have today with the downloadable (and in-sync)
Squeak-dev image: pick the image which fits your needs best.

But on the more pragmatic side: who's going to maintain the non-Etoyless.
I think that's what people are concerned about (and that perhaps induced
confusion into the discussion).

/Klaus

> -- Jecel
>
>

Jecel Assumpcao Jr

Re: here is a plan!

In reply to this post by Juan Vuletich (dc)

Juan Vuletich wrote on Mon, 30 Oct 2006 22:58:32 -0300
> Removing eToys implies deleting "eToys awareness" in lots of methods
> that would not be deleted. Even several instance variables as in
> MorphExtension. I don't know how to offer the user the option for
> removing it, let alone keep that option properly maintained in future
> Squeak versions.

Ok, so this is a rather different project than what I was hoping for.
Some of the problems you mention could be attacked by refactoring and
using Traits but this would imply a lot of changes just to have
essentially what we have now.

So I would like to ask about the plan proposed by Klaus (replacing
Morphic 2.0 with an eToyless Morphic 3.0) what is the level of
compatibility that we would have? Would I be able to grab some old
project from SqueakMap and have it work or would stuff like Celeste, IRC
and others have to be updated?

-- Jecel

Juan Vuletich

Re: here is a plan!

In reply to this post by Juan Vuletich (dc)

Hi Jecel,

I apologize for breaking the thread, but I'm having problems with my
mail provider and I can't answer to your mail.

> Ok, so this is a rather different project than what I was hoping for.
> Some of the problems you mention could be attacked by refactoring and
> using Traits but this would imply a lot of changes just to have
> essentially what we have now.

I agree.

> So I would like to ask about the plan proposed by Klaus (replacing
> Morphic 2.0 with an eToyless Morphic 3.0) what is the level of
> compatibility that we would have? Would I be able to grab some old
> project from SqueakMap and have it work or would stuff like Celeste, IRC
> and others have to be updated?

The "plan proposed by Klaus" seems to be what I'm doing, and you can
download from www.jvuletich.org .
I will not guarantee back compatibility. Anyway, I'm not redoing
PluggableMorphs. And if I do it sometime, I guess that could be back
compatible. After all, the old applications (browser, etc) work the same
with PluggableViews in MVC as with PluggableMorphs. That suggests that
compatibility with that programming model could be kept. Of course,
other morphs most likely will not work.

Cheers,
Juan Vuletich

Juan Vuletich-4

Re: here is a plan!

Jecel Assumpcao Jr

Re: here is a plan!

Juan Vuletich wrote on Wed, 01 Nov 2006 01:00:21 -0300
> The "plan proposed by Klaus" seems to be what I'm doing, and you can
> download from www.jvuletich.org .

Exactly. My impression was that he seemed to think I was suggesting the
same thing, which I wasn't.

> I will not guarantee back compatibility. Anyway, I'm not redoing
> PluggableMorphs. And if I do it sometime, I guess that could be back
> compatible. After all, the old applications (browser, etc) work the same
> with PluggableViews in MVC as with PluggableMorphs. That suggests that
> compatibility with that programming model could be kept. Of course,
> other morphs most likely will not work.

I think quite a bit of the complexity in Morphic 2.0 is due to the need
to keep backwards compatibility with MVC. Of course, that allowed us to
keep using all the great Smalltalk tools we were used to and not having
this might have kept Morphic from ever becoming the main GUI in Squeak.

My last few emails might have given people new to the list the idea that
I want to keep Squeak as it is now. Even more veteran Squeakers might
have found it odd that I, Mr. "burn the diskpacks!" (for new people not
familiar with the term, see the part in Alan Kay's "Early History of
Smalltalk" where he wanted to start over after Smalltalk-76), was
defending the status quo. What I was actually trying to do is to have a
nice discussion about the costs involved. As long as we are aware of
what we are getting into (like Juan, above) I support whatever people
here want to do.

One thing that would be interesting if I had more time would be for me
to compare the various GUIs for Squeak as well as a few related to this.
Perhaps this will be possible next week. I saw two nice MVC links in the
del.ici.us section of Planet Smalltalk today:

http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

And I would suggest that anyone interested in understanding what Morphic
is all about watch the ARK movie (the same guy who wrote the Alternate
Reality Kit in Smalltalk-80 was one of the creators of Self and then one
of the creators of Morphic 1.0):

http://www.open-video.org/details.php?videoid=8050

Another GUI that was developed for Squeak at Disney was PenSprites, but
all we have about that is a paper from OOPSLA 2003. John Maloney (the
other Morphic 1.0 creator, and the main Morphic 2.0 creator) has come up
with a different GUI for Squeak as part of his Scratch project. The
sources for that aren't available, so I can't compare it with Morphic.

-- Jecel

Juan Vuletich-4

Re: here is a plan!

In reply to this post by Juan Vuletich-4

Hi Jecel,

Jecel Assumpcao Jr escribió:

> ...
>
> One thing that would be interesting if I had more time would be for me
> to compare the various GUIs for Squeak as well as a few related to this.
> Perhaps this will be possible next week. I saw two nice MVC links in the
> del.ici.us section of Planet Smalltalk today:
>
> http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
> http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
>
> And I would suggest that anyone interested in understanding what Morphic
> is all about watch the ARK movie (the same guy who wrote the Alternate
> Reality Kit in Smalltalk-80 was one of the creators of Self and then one
> of the creators of Morphic 1.0):
>
> http://www.open-video.org/details.php?videoid=8050
>

Wow. I hadn't seen it before. After watching it, I watched again the
self video. Now I see the linage from Smalltalk-80's MVC -> ARK ->
Self/Morphic1 -> Morphic2 -> Etoys. I'm adquiring insight. I'll try to
put my project in proper perspective. Thank you!

BTW, the machine shown, is it a Dorado?
> Another GUI that was developed for Squeak at Disney was PenSprites, but
> all we have about that is a paper from OOPSLA 2003. John Maloney (the
> other Morphic 1.0 creator, and the main Morphic 2.0 creator) has come up
> with a different GUI for Squeak as part of his Scratch project. The
> sources for that aren't available, so I can't compare it with Morphic.
>
> -- Jecel
>
Yes, I'd love to know more about Scratch!

Cheers,
Juan Vuletich

karl-8

Re: here is a plan!

Juan Vuletich skrev:
> Yes, I'd love to know more about Scratch!
http://weblogs.media.mit.edu/llk/scratch/archives/2006/10/download.html

karl

Juan Vuletich-4

Re: here is a plan!

Thanks Karl!
I'm downloading it right now!

Cheers,
Juan Vuletich

karl escribió:
> Juan Vuletich skrev:
>> Yes, I'd love to know more about Scratch!
> http://weblogs.media.mit.edu/llk/scratch/archives/2006/10/download.html
>
> karl
>
>
>

Juan Vuletich-4

Re: here is a plan!

I downloaded Scratch and could not escape the authoring environment, to
access the Smalltalk tools.

Cheers,
Juan Vuletich

Juan Vuletich escribió:

> Thanks Karl!
> I'm downloading it right now!
>
> Cheers,
> Juan Vuletich
>
> karl escribió:
>> Juan Vuletich skrev:
>>> Yes, I'd love to know more about Scratch!
>> http://weblogs.media.mit.edu/llk/scratch/archives/2006/10/download.html
>>
>> karl
>>
>>
>>
>
>
>
>

Bert Freudenberg

Scratch (was: Re: here is a plan!)

That's expected - it is a closed authoring tool, in contrast to
etoys. Very nicely done, though.

- Bert -

Am 04.11.2006 um 18:39 schrieb Juan Vuletich:

> I downloaded Scratch and could not escape the authoring
> environment, to access the Smalltalk tools.
>
> Cheers,
> Juan Vuletich
>
> Juan Vuletich escribió:
>> Thanks Karl!
>> I'm downloading it right now!
>>
>> Cheers,
>> Juan Vuletich
>>
>> karl escribió:
>>> Juan Vuletich skrev:
>>>> Yes, I'd love to know more about Scratch!
>>> http://weblogs.media.mit.edu/llk/scratch/archives/2006/10/
>>> download.html
>>>
>>> karl
>>>
>>>
>>>
>>
>>
>>
>>
>
>