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(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061028/8b0e347d/attachment.htm