At 10:40 PM 10/7/98 -0400, you wrote:
Lack of documentation is (IMHO) more of a problem
I remember somewhere (in one of those earlier SqueakIntro Window?) someone has said that one of the goals in Squeak is to make it a self described object thru hypertext. In my opinion, after spending some time working in Squeak, even judging based on the current state of Squeak, it is already very readable and quite easy to follow. I particular like little tools like the question mark for class documentation (which majority of the classes has put comments in this pane); the consistent usage of category (although I think some of the new classes in 2.2 has diverted a little bit) for easy navigation and method location (e.g. public access, instance creation etc.); the 'explain' menu option etc etc. But to me, the biggest documentation in Squeak is its complete openness of its class sources, its VM, its system (e.g. Compiler, Encoder) etc. These are something that I dearly miss in IBM Smalltalk.
Of course you have to have certain knowledge in Smalltalk in order to know how to poke around the system. So for beginner, there are supplementary on-line document and tutorials available in Squeak central web site in UIUC. These tutorials can be improved, I agreed.
As a side note, I would have to say that Squeak is not only good for learning Smalltalk/OO but a good live document for computer science in general. I think Squeak would be an ideal environment to teach, demo, explore and even change/extend for any computer science class ranging from graphics, compiler, electronic music, internet programming, networking, .... and you name it.. and I won't be surprise that one day when I open my Squeak image, I don't ever need to open up any applications (e.g. Word, netscape, Eudora) since I can do all these from within Squeak.
In short, I would very much like to see the future improvement of Squeak documentation focus on within rather than external. -- Mark Wai Wator Innovision mailto: mwai@ibm.net or:[ mwai@frontiersa.com] __
Thanks Mark --
At 4:59 AM -0000 10/8/98, Mark Wai wrote: -- snip --
As a side note, I would have to say that Squeak is not only good for learning Smalltalk/OO but a good live document for computer science in general. I think Squeak would be an ideal environment to teach, demo, explore and even change/extend for any computer science class ranging from graphics, compiler, electronic music, internet programming, networking, .... and you name it.. and I won't be surprise that one day when I open my Squeak image, I don't ever need to open up any applications (e.g. Word, netscape, Eudora) since I can do all these from within Squeak.
This, in a nutshell, is one of our main nearterm goals -- especially (a) a "total" environment, and (b) "a good live document for computer science in general".
All on the Squeak list, please think about helping this along over the next year.
Cheers,
Alan
Alan Kay said:
Thanks Mark --
At 4:59 AM -0000 10/8/98, Mark Wai wrote: -- snip --
As a side note, I would have to say that Squeak is not only good for learning Smalltalk/OO but a good live document for computer science in general. I think Squeak would be an ideal environment to teach, demo, explore and even change/extend for any computer science class ranging from graphics, compiler, electronic music, internet programming, networking, .... and you name it.. and I won't be surprise that one day when I open my Squeak image, I don't ever need to open up any applications (e.g. Word, netscape, Eudora) since I can do all these from within Squeak.
This, in a nutshell, is one of our main nearterm goals -- especially (a) a "total" environment, and (b) "a good live document for computer science in general".
All on the Squeak list, please think about helping this along over the next year.
I don't know. I've used Smalltalk, Forth, and Lisp (Macintosh Common Lisp, Harlequin's LispWorks on Unix and Gnu/X emacs) environments, all of which are "unitary" environments that try to be total. I also use unix under Xwindows on a daily basis.
I think, in general, I prefer the "separable" environments where I have a broad spectrum of small tools I can use whenever I want. It's very easy to incorporate new tools, or to try out somebody else's great ideas.
When I had the job of interfacing Harlequin's LispWorks with the ClearCases change control system and Task Tracking System we'd developed around Quintus's QualPro(?) database system, I spent some time thinking about the issues involved. This was an early version (version 2) of ClearCase and they'd assumed a separable environment, with no mechanism to change the view of the file system provided to a running process. We had to find a way around that problem to be able to use it from within the Lisp environment, since we were unwilling to take the time (on the order of minutes) to get out of Lisp and back in every time we needed to change views. The system we were developing had originally been developed on Symbolics machines, where Lisp was the Total environment, and ported to Sparc machines running Unix or RTX.
I may be wrong, but my take on it was that the major advantage the unitary environments provided, and the major impediment to making them separable was that the services they provided were a superset of those provided by current operating systems. In particular, they provide alternative memory management / garbage collection. (Well, forth does it's own memory management, but not gc ). So far as I know, the process management capabilities are basically duplicates of that provided by the operating system.
If one were to be able to push the memory management into the operating system, would we still need unitary environments?
Well, as soon as I wrote that, I realized that a better way to state it is that the VMs these environments provide differ from the implicit VMs provided by typical operating systems. The VMs define not only the memory management models, but also file system, process management, and intra- and inter-process communication mechanisms. Still, it seems the major hurdle is the memory management, because all the unitary environments I know, even modern Forth environments, can use the OS's filesystem and can interoperate with other OS processes.
So, a question to consider: If NGOS (the Next Great Operating System) were to include generational garbage collection at the process level, would it still be advantageous to maintain the unitary environment, and why?
If not, could we open up the Squeak VM a bit, to allow partial separation, or separation that included memory management facilities as part of the separated pieces?
It seems to me that GNUemacs or Xemacs may be good models of what such an environment would be like. They allow me to run separated tools as "inferior" processes, at least on Unix systems, capturing the output and interacting with them using the other services provided by the OS.
Perhaps Java, (simplified C++ with garbage collection), is/will be popular enough to get people beyond their fear of garbage collection. If so, moving real memory management into the OS might provide an opportunity to try something really new with Squeak, or its grandchild...
If you really want a project, consider how the OpenSource community might push Linux in that direction...
Or, thinking of MkLinux on my PPC machine, what if the SqueakVM were an alternative library to run on the Mach kernel...
Well, that's probably enough bandwidth used for now...
joe
Joe Davison wrote:
....
If one were to be able to push the memory management into the operating system, would we still need unitary environments?
Well, as soon as I wrote that, I realized that a better way to state it is that the VMs these environments provide differ from the implicit VMs provided by typical operating systems. The VMs define not only the memory management models, but also file system, process management, and intra- and inter-process communication mechanisms. Still, it seems the major hurdle is the memory management, because all the unitary environments I know, even modern Forth environments, can use the OS's filesystem and can interoperate with other OS processes.
So, a question to consider: If NGOS (the Next Great Operating System) were to include generational garbage collection at the process level, would it still be advantageous to maintain the unitary environment, and why?
Having been in the Smalltalk VM porting business for over 10 years now I can say that the more services you use from the underlying OS, the more trouble you have. Eliot Miranda can probably tell you more about the dubious pleasure of using the pthreads functions on half a dozen Unices (hint: most of the implementations are incomplete or so buggy that you need more code to work around them than to use them). The same goes for supporting different file systems, different window systems, different network communication systems etc. In contrast, everything implemented within the VM (or better, in the image) is very portable and debuggable.
....
Or, thinking of MkLinux on my PPC machine, what if the SqueakVM were an alternative library to run on the Mach kernel...
Now that's a good concept! I've thought about that, too. Having Squeak as a personality on a Mach Kernel is as good as a native SqueakOS, or maybe even better because you can run it in parallel with other OSesthat you might need. Too bad that my Performa does not yet run MkLinux, otherwise I would probably have started that project already...
Hans-Martin
> Or, thinking of MkLinux on my PPC machine, what if the SqueakVM > were an alternative library to run on the Mach kernel...
Now that's a good concept! I've thought about that, too. Having Squeak as a personality on a Mach Kernel is as good as a native SqueakOS, or maybe even better because you can run it in parallel with other OSesthat you might need. Too bad that my Performa does not yet run MkLinux, otherwise I would probably have started that project already...
What are the implications of this? What does it mean to have "Squeak as a personality" as opposed to having Squeak as an application?
It may not be good form, but let me reply to my own posting, since I want to discuss a piece that, so far, no-one else has discussed.
Joe Davison said:
Alan Kay said:
This, in a nutshell, is one of our main nearterm goals -- especially (a) a "total" environment, and (b) "a good live document for computer science in general".
All on the Squeak list, please think about helping this along over the next year.
I don't know. I've used Smalltalk, Forth, and Lisp (Macintosh Common Lisp, Harlequin's LispWorks on Unix and Gnu/X emacs) environments, all of which are "unitary" environments that try to be total. I also use unix under Xwindows on a daily basis.
I think, in general, I prefer the "separable" environments where I have a broad spectrum of small tools I can use whenever I want. It's very easy to incorporate new tools, or to try out somebody else's great ideas.
My biggest problem with the Unitary Squeak environment is that I have a "real" job that I have to do that does not revolve around Squeak. On the other hand, I'd love to be able to use Squeak to help me do that job.
That means I MUST be able to integrate Squeak with other tools. Another part of my previous post was relevant here:
It seems to me that GNUemacs or Xemacs may be good models of what such an environment [should] be like. They allow me to run separated tools as "inferior" processes, at least on Unix systems, capturing the output and interacting with them using the other services provided by the OS.
I've not looked recently -- is there a Squeak equivalent of an emacs Shell interaction window? That is, a window where what I type is fed to another "unix" process and the output from that process is captured and displayed? That goes a long way to doing what I want, and would probably provide an example from which to build extensions...
joe
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Hans-Martin Mosner -
jwdavison＠lucent.com -
Mark Wai -
Patrick Logan