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 Smalltalkhttp://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(most?) 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 on oth er 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 that a coupl e 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
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, mmille10@comcast.net 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
Guy Bloomfield wrote on Sat, 28 Oct 2006 19:30:14 +1300
- 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
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
- 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
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
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, mmille10@comcast.net 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.
squeak-dev@lists.squeakfoundation.org
-
Guy Bloomfield -
Jecel Assumpcao Jr -
Juan Vuletich -
mmille10＠comcast.net -
Todd Blanchard