Squeak in IEEE Software
ivan.tomek at acadiau.ca
Mon Feb 1 22:01:01 UTC 1999
About five years ago, I wrote an on-line help system with the help of
some students. The idea was that
-several kinds of help and an information repository are needed by all
programmers and that
- this repository needs to be programmer-commuity based while being
individually editable. Like open software, the commuity contributes to
this knowledge base, maintains its correctness, and makes it grow.
I presented my ideas at a ParcPlace conference when ObjectShare was
still ParcPlace just after it merged with Digitalk and the company was
then interested in implementing it.
As far as the tool is concerned, I provided several categories the list
could be extended by the user) including a glossary, a 'how to do it'
tool with subcategories such as UI, streams and files, etc. (for
situations when you basically don't know how to start), class help
(with information about the purpose and proper use of selected
classes and their defined or inherited methods (with examples of
code), 'how things work' with an explanation of subsystems, etc. A
'history' category might be useful, and version support, possibly
linked to software releases might be useful too.
Everything was cross-linked, searchable, executable, and linked to the
I proposed that this kind of tool could be shared by the Smalltalk
community and managed by an 'editorial board' responsible for the
correctness of the shared information and its regular releases. The
board would have access to expert volunteers who would help
filtering and editing contributions from the community.
One of the ways in which I used this tool was to record in it my
discoveries - I find that eve when I spend a lot of time figuring out
how to do something, I can forget it very quickly and have to
rediscover it painfully next time. A searchable structured tool that
allows me to record my findings in such a way that I can find them
again easily is very useful. For a group, the tool and its contents can
become a part of 'group memory'.
My students found the tool very useful and a resource like this might
be useful to support a living archive of structured Squeak information.
> On Mon, 1 Feb 1999, Dan Ingalls wrote:
> > The lines of code thing is just plain confusing. Generally less is
> > better, and I just don't think you cn compare systems this way.
> > Consider...
> > | strm |
> > strm := WriteStream new on: (String new: 10).
> > tempNames do: [:n | strm nextPutAll: n; space].
> > tempStr := strm contents.
> > versus...
> > tempStr := String streamContents:
> > [:strm | tempNames do: [:n | strm nextPutAll: n; space]].
> > The streamContents: form encapsulates a variable declaration, a stream
> > creation, and the extraction of a stream's contents. Every time it
> > gets used reduces opportunities for errors in those places. And you
> > can be pretty sure that streamContents: is correct, because it has
> > been in use every millisecond for the last three years that the
> > current Squeak image has been running (think about it ;-).
> Your choice of example was particularly interesting to me. As I am still
> new to Squeak and Smalltalk, even though I consider myself an experienced
> programmer (and a very good C++ and Java coder), I'm occasionally
> frustrated by the learning curve to write code that feels like Squeak,
> mostly because I'm not familiar with what the class libraries can do. The
> only solution is simply to get more practice writing code, and that's what
> I've been trying to do.
> For example, performance is important to me, and one of my long-term goals
> is to be able to help in some way with the Jitter project, so I've been
> reading the Dragon book and converting the examples to Squeak. For the
> first example (an infix-to-postfix translator), I ended up writing some
> code exactly like your first example. I strongly suspected that there was
> a better way to do it (it just didn't feel right), but it was amusing to
> see you answer my question before I had a chance to ask it!
> What does this mean for Squeak, particularly in terms of making it
> accessible to programmers, like myself, who already know C++ or Java, but
> aren't familiar with Smalltalk? I suspect that as Squeak gains in
> popularity, more of these programmers will come in and start writing C++
> or Java-looking Squeak code, and anything which can be done to improve the
> situation is a good thing. The ability to easily browse any source code
> in the system is a real plus, simply because exposure to high-quality code
> in any language is a great way for the coding style to rub off on
> However, what I really miss is the equivalent of books like "Java in a
> Nutshell", which features a highly lucid quick reference to all Java
> classes, and tips on how they are intended to be used. While Java already
> came with javadoc descriptions of each class, it was often difficult for
> me to see exactly where to begin, and it's all too easy to skip over a
> method which may be exactly what you need. Referring back to my Squeak
> experience, even though I had full access to browse the messages for
> String and WriteStream, I just didn't see the streamContents: message.
> Anyway, since you had mentioned better documentation as a goal for future
> Squeak releases, I hope these comments give you some idea of the sort of
> documentation I (and presumably many others like me) would find very
> useful. It doesn't have to be a printed book: in my case, simply having
> a brief summary of commonly used messages (ideally with example code
> snippets like the one you gave) summarized in the help text for each
> system class (so I can hit the ? button and read how to use it) would be a
> BIG improvement.
Jodrey School of Computer Science
Nova Scotia, Canada
fax: (902) 585-1067
voice: (902) 585-1467
Go Smalltalk - the language for people (and for computers)!
More information about the Squeak-dev