Smalltalk & Squeak featured on Slashdot

[Karl Ramberg]

Les Tyrrell wrote:
>
> ----- Original Message -----
> From: Karl Ramberg <***@chello.se>
> To: <***@cs.uiuc.edu>
> Sent: Monday, April 30, 2001 1:26 PM
> Subject: Re: Smalltalk & Squeak featured on Slashdot
>
> >
> >
> > Les Tyrrell wrote:
> > >
> > > Glyph Lefkowitz wrote:
> > > >
> > > > On Monday 30 April 2001 03:55, Stephane Ducasse wrote:
> > > > > And this would be great to have classes that have less than 200 methods ;).
> > > > > In the same idea, I strongly think that string does not have to know
> > > > > asURL
> > > > > as....
> > > > > asblabla
> > > > >
> > > > > Because then everything is linked together.
> > > >
> > > > I doubt that this is feasible w/ squeak, but in a perfect world, asURL
> > > > asBlaBla and friends *would* be part of String, but they would also have a
> > > > module they were associated with; so you could browse methods by class or by
> > > > module. In theory, module dependencies could be automatically computed,
> > > > then...
> > >
> > Wouldn't these thing be easier if there was sideways relation,
> > inheritance from several classes ?
> >
> > Karl
>
> In this case, I would argue against that- the problem, as I see it, is that these methods
> fundamentally do not belong where they are being found. This is a symptom of a bad design, not a
> tools issue per se. Where I would argue that tools have a role in this is to discover where such
> things are going on, and to make this sort of thing more visible to the programmer in a way that
> clearly depicts this as NOT being the preferred manner in which to introduce new capabilities into
> the image. That is the angle I am taking with Oasis, as described a bit below.
>
Ok. The funktionality in Oasis seem really cool. What would the image
size be if
you ran this after major shrink and deleted all the fluff?
Karl
> - les
>
> > > These things are basically possible.
> > >
> > > If you take a chunk of code which represents the most visible bits of functionality of
> > > some prospective module, you will discover within it usage of certain selectors in certain
> > > contexts. These can be located, and it is possible to identify these with both their
> > > usage and their implementations. Do enough of this, and you can probably assign chunks of
> > > selectors ( call them interfaces if you wish ) to both the module which uses them (
> > > exclusively, perhaps ) and the classes which have been extended to support such modules.
> > > I developed just such an analytical capability in Oasis for just this sort of task- it was
> > > meant to assist in the modularization of lots of non-modular code. When I started it, I
> > > thought I would be mainly interested in VisualWorks, but since then the same sorts of
> > > problems have begun to plague Squeak to an even greater extent.
> > >
> > > If you do this, then you have knowledge of which selectors are extensions and which are
> > > intrinsic properties of the various "base" classes. You then "know" more clearly what
> > > belongs in those "base" classes, and what is fluff- too much fluff is not a good sign.
> > >
> > > > It's really powerful to be able to add methods to Object, sometimes; but it
> > > > would be really neat if you could take those methods *OFF* too :)
> > >
> > > If you know which ones they are, this is trivial.
> > >
> > > - les
> >

[Tim Rowledge]

> I'd like to have a better understanding of
> - who is harmed by the present image size? (what _kinds_ of users)
> - how many people are harmed by the present image size?
> - how badly are they harmed?
> - in what ways are they harmed?
> - are there any proposed solutions that would, over-all, do less harm?
Some possible answers I can imagine in response to these questions
a) who is harmed?
anyone wanting to use Squeak on small machine, especially an embedded
use with no virtual memory. Anyone that finds the vast extent of the
image intimidating, so much to gaze at! Anyone writing code that wants
to move it from one version image to another; so much to try to check
for changes that will affect it.
b) how many?
No idea. Putting tongue firmly into cheek (note to self ; stop chewing
on inner cheek, it's making a scar lump) I could suggest that all XX
million Palm users are suffering, but they have a congenital problem in
the memory system anyway, so screw'em.
c) how badly?
For the embedded/small machines, moderately - you can play with the
assorted shrinking stuff , but it gets tedious and is not terribly precise.
For people intimidated, possibly a lot. Some people get really worried
by the size of the system. Hell, I get vertigo sometimes and I've been
doing this longer than some countries have existed.
For code supporters, it can be really bad, enough to put them off
keeping code alive even. This potentially harms us all in some manner.
d) how are they harmed?
sorta answered above.
e) solutions?
Mostly improvements in tools of various sorts.
Modularity can help massively; but it's not just chopping the system up,
it's making tools to help(force?) people to keep modules modular.
Modularity would probably make those dreadful forks unneccesary, since
you can get the system you want just by binding to the modules that give
it to you.
Change tracking tools and data would help a great deal with making it
easier to forward port code. The change file browser is a big help in
many respects, but it can't do much to help find moved code, track down
other changes that might affect you (by bypassing a method you were
depending on, for example) and other problems. I fall back on the normal
pathetic excuse of lack of time to examine Oasis to see how it might help.
One tool I imagine might help is a website(?) that an image can query to
find the _full_ history of a method/class/group of code/whatever, a bit
like a super-extended versions browser.
>
>
> While I affirm that Squeak's size is not out of line, compared with other
> programs and language implementation, there are many other reasons to want
> modularity.
Once upon a time VisualWorks was considered a huge application, needing
extra memory, costing money to support etc. These days I doubt it
matches the sizes of the spelling checker assistant for Word. Didn't I
hear that Word 2002 was going to come on 2 DVD's?

^. .^
='=
tim

[John R. Hall]

On Thursday 19 April 2001 01:41, Richard A. O'Keefe wrote:
> The student wrote:
> >>> The Squeak IDE is one of the most frustrating pieces of software
> >>> I've ever had to use.
>
> Compared with what, I wonder? I've been using computers since 1974
> and GUIs since 1984. Windows gives me screaming fits from frustration.
> MacOS makes sense, but Inside Macintosh made Squeak documentation look
> good. Metrowerks is a pain. I once spent a couple of hours trying to
> write Hello World in IBM's Visual Age for C++ and failed. (Maybe a
> printed manual would have helped...) I use Sun's Workshop moderately
> frequently.

I wasn't the student who posted that, but I share the sentiment. I mention
the following points as someone who sees a lot of potential in Squeak, but
who has had less than a fully positive experience with it over the past few
months. Please do not take this as a flame.

-The first few days with Squeak were very difficult. I really didn't know how
to do anything in the environment. I got over that, but it could have been a
more positive experience. This isn't really Squeak's fault; it just happens
that Squeak's interface is considerably different from anything else I've
ever seen.

-Squeak's intense reliance on the mouse is likely to be frustrating for
basically anyone but hardcore Macintosh users. I've heard all sorts of
excuses for this, including at least one misapplication of Fitt's Law and
various experimental data to show that mousing is faster than keyboarding.
(It's true that mousing is often faster for new users in _unfamiliar
environments_; keyboarding can become a much faster means of input for
experienced users who know the shortcuts. A bit of keyboard window navigation
would work wonders.)

-I've heard amazing success stories of Squeak images running continuously for
years at a time, but over the past semester of working with Squeak for a
class I've lost at least 3 hours of work due to random crashes and lockups.
Recovering code from the changes file is a major PITA. To make matters worse,
our class' Swiki crashes on a regular basis, frequently on the night before
projects are due (this has happened at least twice out of six project
deadlines). It's FAR too easy to fry an image. I've managed to do it
accidentally several times.

-The user interface is... well, clean, I guess... uncluttered, maybe... not
very pretty. I tried to spice it up a bit with various goodies, but that
fried my image pretty quickly.

-The system is supposedly self-documenting, but much of the system is left
uncommented and without help boxes. This makes it very difficult for
beginners to learn the basic system classes. I've spent many red-eyed nights
untangling the code to try to figure out what's going on, and I usually
succeed, but a few more bits of documentation would help greatly. (Yes, I
know, programmers hate to write documentation, and I'm pretty bad about it
myself, but this small bit of effort would go a long way.)

-Morphic. This graphical scripting stuff sounds like a neat idea, but I took
one look at such a "script" and found myself asking "WTF??"
The Morphic environment is teeming with cool features, but how the heck is a
newbie supposed to figure them out?

The Smalltalk language is great. It's been difficult getting used to the
Squeak system, though. Learning GNU Emacs was more difficult but less
frustrating than becoming basically competent in Squeak. I'm starting to like
it more as time goes on, but I don't know if I'll use it when I'm out of "The
Squeak Class" (CS2340 at Georgia Tech).

So, yes, I can understand why a student might proclaim frustration with
Squeak.

-John

--
Underfull \account (badness 10000) has occurred while \spend is active
John R. Hall - Student, Georgia Tech - Contractor, Loki Software

[Paul Fernhout]

Glyph Lefkowitz wrote:
> As a newcomer to squeak myself, I've had a lot of these problems too.> > [Snip: comments at]
> http://twistedmatrix.com/users/glyph/rant/sqcr.html
>
> Feedback will be appreciated!

I enjoyed your write up. It takes a certain set of skills to be able to
produce such a detailed and well written set of issues from a first-hand
perspective, and thanks for doing it.

You get pretty much complete agreement from me. I came to Squeak from a
lot of recent experience in Delphi and VisualWorks, and I found both
easier to construct at least simple applications in (well, VisualWorks
took some more work on the GUI side but shined in other areas).

I especially likes these points from your detailed web page:
> I downloaded approximately 50 changesets,
> and every single one either gave me a walkback upon
> filein or conflicted with another seemingly innocuous changeset
> in such a way that a basic task (opening a
> Browser window, or better yet, entering the debugger)
> would give me a walkback.
> [snip]
> Despite the pleasantness of the debugger, the sea of broken links,
> broken instructions, and broken code only gave me three conclusions
> to jump to:
> [snip]
> 3. It is nigh impossible to actually write and maintain a significant
> amount of code which stays current with
> the SqC image, despite many heroic efforts to the contrary;
> so you have to have 6 or 7 different images
> lying around that you can actually run squeak code.

On my system right now I have (at least) 1.13, 2.2, 2.7. 2.8, and 3.0
each for a different reason. I'd agree #3 is the big issue. As is lack
of time for many people (including those at Disney who have to deliver
applications instead of Squeak improvements) which may lead to a bit of
#1.

And your conclusions:
> Why It's Worth it Anyway
> While these problems are certainly significant, and even if the
> community were already 100% dedicated to fixing them,
> it would take a while to get to the point where they were all
> solved, they are at least theoretically solvable.

Agreed.

And that is the issue delaying several people's use of Squeak for big
things, myself included. I figured a while back it would take four
months of an experienced and "in-the-groove" Squeak developer to make
the base of Squeak useable for many (not all) commercial quality things
on one platform. This has improved since then, but it still is a big
chunk of time; why dealing with fonts alone chewed up a lot of people's
time with licensing issues, discussion, etc.

I almost did that push anyway for a 2.0 version of one of our products,
but ultimately the risk seemed too high (given SqueakC's relentless
advances in a Morphic direction) and we stuck with Delphi for our 2.0.
Yet we have endless requests for a Mac version, and Squeak would
otherwise help us do that. Yes, VisualWorks is an alternative obviously,
but I wanted an open-source platform. DrScheme also comes close, being
open source and cross-platform (and modular), but lacks some of Squeak's
other transcendent features.

> I don't believe that, for example, giving Python real automatic
> orthogonal persistence, or speeding up the interpreter by a
>factor of 10 to 25, is solvable in any practical timeframe.
> Or making C or C++ a reflective language. Squeak solves some
> very basic problems pretty well, and addresses issues that
> most other environments and languages just ignore.

Agreed, with a reservation. Modularity is a basic thing. Squeak gets
almost every other basic thing right because it is based on Smalltalk
which got them right, but modularity isn't something that is easy to
"patch in". In fact, if you are modular, almost everything else is
easier to patch in. Python and C/C++ still tempt me over Squeak because
they are modular. For example, I can use any of several snappy GUIs with
Python (TK, wxWindows, SDL, etc.). And solutions to these problems have
been handled in different ways because of that modularity (Python
extensions in C, sections of C code written in an OO style or bundling
in Python as an extension language).

I think there is a fundamental paradigm issue here. The original
Smalltalkers now at SqueakC pioneered the notion of an interactive
personal development environment. They gave the world something really
incredible that in many ways still has not been surpassed by anything.
Given this and the small systems of the day, and that all the
Smalltalkers at Parc worked together, and incredibly brilliant people
like Dan or Adelle were there to smooth over rough edges with
hand-holding, modularity wasn't a big deal in the early days. Also, some
people are rightfully proud that the image has been "alive" since then,
like some sort of a pet. It seems to me some people are happy with the
notion of a million different images, each laboriously maintained by a
reasonably skilled (or quickly learning) user, because for them it is
part of the success of the initial vision and the initial paradigm.

The UNIX world which grew out of Bell Labs (whose traditions spawned
C/C++ and to an extend Python/Amoeba) for example has a different
paradigm. That is a hierarchy of protected resources, reflected in the
UNIX file system. It even is reflected to an extent in how the Linux
effort works -- Linus at the top in charge of the kernel with CVS
checking privileges for that code, with others in various groups in
charge of tools that run on Linux with permissions to commit changes to
those (like as on SourceForge). However, even in the Linux world there
are organizations like RedHat with their own local privileges to decide
what set of versions of specific components together comprise a release.

Manual De Landa in his book "A Thousand Years of Non-Linear History"
talks about "hierarchy" and "mesh-works" as two organizational forces
that are always intertwining on a practical basis. The problem we have
here is a basic difference in slant from SqueakC and developers coming
from a Unix (or commercial) background. The original Smalltalkers must
believe in mesh-works, but we are saying Squeak needs a bit more
hierarchy. The reality is probably that something in the middle is a
better thing than being at either extreme.

> However, making the virtual machine modular, adding namespaces,
> fixing the UI [etc] is a difficult, but eminently possible task.

Agreed. Having pluggable primitives is already there to an extent
(yahoo!) as a nod to modularity, but the deeper issues of modularity
(vm-to-vm remote debugging), namespaces, and alternative "classic" GUI
are big things. Still, these can be helped along with fairly minor
concessions -- again, GNU Smalltalk has some good rough-and-ready ideas
here.

> The problems I've enumerated here are some of the things I hope
> to work on as I work with Squeak.

You and many other people! Some of whom come to this list periodically
and then drift away... However that urge will only persist if we think
the base is stable enough so our efforts don't get swept away. Since
many of these issues are core ones, the likelihood of obsolescence
happening is high. Open source may draw a lot of effort, but what good
programmer wants to see their effort lost? There needs to be a group
that has a mainline distribution with an emphasis of addressing these
issues. (SqueakFoundation?)

I wish that the stable branch was at the root of SqueakCs work, but it
doesn't seem to be the case, possibly in large part for ideological
reasons mentioned above (mesh-work vs. hierarchy). Hopefully the
community is strong enough finally that it can withstand a fork, which
seems imminent (with Stable Squeak). My prediction is that within a year
if a fork happened and took off, no one will want the SqueakC
distribution, except to load specific add-ons from Disney to a stable
release. But there is a high cost for everyone to pay -- both people
making the quantum jump to support a new release, the intermediary
confusion and ambiguity (is stable Squeak really going to take off?) and
the final issues of SqueakC reintegrating their own work with the stable
base as a module.

Personally I would love to see Apple and/or IBM (both large
organizations who benefit from supporting cross-platform standards) play
a hand in underwriting or coordinating this effort, possibly through a
chaordically organized Squeak Foundation, perhaps under a more
conventional open source license like BSD or LGPL if Apple was involved,
with an effort made to clearly get every contribution starting from 1.13
on under an explicit license and statement of origininality (yet another
issue!). I find it hard to believe for example there is no one left at
Apple who sees Squeak's strategic value to Apple's prospering. Still, I
think even without them there are more than sufficient resources and
skills on this list to make this happen as a cooperative effort, and it
is already happening, although in fits and starts. It's just too bad it
required a fork.

However, the essential thing to remember is the most important aspect of
Squeak is the community and this mailing list. If we all "burned the
disk packs" I'm sure this crowd could have a better Squeak up and
running in six months! (Probably with protoypes like Self.) Whatever is
done, I think an essential aspect of any effort has to be to keep the
Squeak community strong and growing.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

[Tom]

On Thu, Apr 19, 2001 at 09:42:07AM -0400, Bijan Parsia wrote:
> Anyhoo, none of our flapping gums is going to do much, since all these
> lines are well known. Code is prolly more convincing.

I'm sorry, but that wasn't at all my point. This isn't about code,
it's about keeping an open mind. Without an open mind, no amount of
code contributions is going to help.

Your impression of Emacs as "slow, annoying, clunky" is just the
same as that student's first impression of Squeak. And both those
first impressions are justifiable, in my opinion. But I have never
encountered a system that has been around for a few decades and doesn't
have some really nifty functionality under the covers. If you aren't
willing to get beyond the "slow, annoying, clunky" view of a successful
system, you can't learn why it is successful in the first place.

How much of that you then translate into your preferred system is
an entirely separate question.

> Yes, and this is the big problem: what's in Emacs that is *part* of the
> success that is *nevertheless* translatable to the Squeak context *in such
> a way* to promote Squeak's "success".

I think that's a separate question. My personal opinion is that an
advanced IDE should have automatic window management and it should have a
very rich set of key bindings. But other's preferences may differ;
not all people are alike.

But to attract new users, I think the main issues are the ability to
customize the system to reduce cognitive load, the ability to solve
real-world problems easily out of the box, and quick, unobtrusive obvious
paths for access to relevant help and documentation. Emacs hardly shines
in these areas. Squeak actually has a much better chance, since most
of the bits and pieces already exist (key bindings, customizable LAF,
OS interfaces, GUI widgets, help system); with Squeak, it's less about
programming and more about packaging.

Cheers,
Thomas.

[Tom]

On Fri, Apr 20, 2001 at 07:08:31AM -0400, Andrew C. Greenberg wrote:
> > in these areas. Squeak actually has a much better chance, since
> > most
> > of the bits and pieces already exist (key bindings, customizable
> > LAF,
> > OS interfaces, GUI widgets, help system); with Squeak, it's less
> > about
> > programming and more about packaging.
>
> I don't get this. Why is Squeak "more about packaging?" To me, Squeak
> is more about the amazing power it has under the hood.

Ummm... you misunderstood; what I was suggesting was: "making Squeak more
beginner-friendly is more about packaging existing pieces, rather than
programming a lot of new functionality, because the pieces themselves
already exist and do not need to be written from scratch (unlike, say,
if you had to do the same for Java)".

Thomas.

[Christopher Sawtell]

On Thursday 19 April 2001 05:10, Kevin Fisher wrote:
> On Wed, Apr 18, 2001 at 08:45:34AM -0700, Michael Rueger wrote:
> > Wouter Gazendam wrote:
> > > Might be an interesting advocacy:
> > > http://slashdot.org/article.pl?sid=01/04/18/001236&mode=thread
> >
> > Oh boy, Tim you where so wrong about the average IQ of the people
> > posting there...
> > You just can't stop being optimistic, can't you?
> > ;-)
> >
> > Michael
>
> Must...resist..masochistic...urge...to...check..Slashdot...
>
> Is it really that bad? :)

Only if you don't login and set yourself a threashold of 3 or 4.
Doing that censors out most of the rubbish.

--
Sincerely etc.,

NAME Christopher Sawtell
CELL PHONE [phone]
ICQ UIN 45863470
EMAIL csawtell @ xtra . co . nz
CNOTES ftp://ftp.funet.fi/pub/languages/C/tutorials/sawtell_C.tar.gz

-->> Please refrain from using HTML or WORD attachments in e-mails to me <<--

[Roel Wuyts]

Maybe slightly of-topic but I couldn't resist:

On 19/04/01 15:42, "Bijan Parsia" <***@email.unc.edu> wrote:
> [snip]
> (Though, not always...e.g., there have been several goodies over the years
> to give some basic emacs keybindings to Squeak (and other
> Smalltalks). They mostly haven't caught on. Now a sensible interface for
> adjusting keybindings, etc. etc., would be very nice!)

I just released MagicKeys, a graphical utility for doing just that: viewing
and adjusting keybindings (and importing/exporting them). It even comes with
some e-macs like keybindings. Check out the webpage at
http://www.iam.unibe.ch/~wuyts/magickeys/ for more information and some
screenshots to see what I mean. It is for VisualWorks, but could of course
be ported to Squeak.

The implementation consists of two parts:
(1) reading an instance of DispatchTable, and converting it to something
that makes sense and is readable (and converting that back to a dispatch
table). This was the hard work: reverse engineering the dispatch table,
paragraph editor and FeelPolicy.
(2) the GUI to capture keystrokes, define keybindings, sort them, etc.

I can have a look to port (1) in Squeak (which is necessary to port the
GUI), but I don't have the time to create the -for the user- all important
GUI part.... Anybody up to the challenge ? Maybe we can do this at the
Stable Squeak event at ESUG in Essen ?



--
Roel Wuyts Software Composition Group
***@iam.unibe.ch University of Bern, Switzerland
Board member of the European Smalltalk User Group: www.esug.org

[Mark Mayfield]

At 07:34 AM 4/19/2001 -0800, you wrote:
>Guess where the Interlisp-D environment came from ..... and when ... and
>what code was used to do its window system .....

I'll take a guess...

Built on an Xerox Alto using Smalltalk's byte-code interpreter.

Mark

[Alan Kay]

Mark --

Built on an Alto by Bob Sproull using Dan's bitBlt code to do the
windows and other GUI, which were modeled after the ones already in
Smalltalk. In the early days, Interlisp ran on the MAXC (our fake
PDP-10) and Bob built a smart terminal for Warren Teitelman using the
Alto. I believe this was the first time someone had done the right
occlusion clipping code so that you could have several processes
running in several windows concurrently, even if they were overlapped.

Cheers,

Alan

-------

At 9:45 AM -0500 4/19/01, Mark Mayfield wrote:
>At 07:34 AM 4/19/2001 -0800, you wrote:
>>Guess where the Interlisp-D environment came from ..... and when
>>... and what code was used to do its window system .....
>
>I'll take a guess...
>
>Built on an Xerox Alto using Smalltalk's byte-code interpreter.
>
>Mark

[Glyph Lefkowitz]

On Monday 30 April 2001 03:55, Stephane Ducasse wrote:
> And this would be great to have classes that have less than 200 methods ;).
> In the same idea, I strongly think that string does not have to know
> asURL
> as....
> asblabla
>
> Because then everything is linked together.

I doubt that this is feasible w/ squeak, but in a perfect world, asURL
asBlaBla and friends *would* be part of String, but they would also have a
module they were associated with; so you could browse methods by class or by
module. In theory, module dependencies could be automatically computed,
then...

It's really powerful to be able to add methods to Object, sometimes; but it
would be really neat if you could take those methods *OFF* too :)

--
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
http://twistedmatrix.com/users/glyph

[Karl Ramberg]

Les Tyrrell wrote:
>
> Glyph Lefkowitz wrote:
> >
> > On Monday 30 April 2001 03:55, Stephane Ducasse wrote:
> > > And this would be great to have classes that have less than 200 methods ;).
> > > In the same idea, I strongly think that string does not have to know
> > > asURL
> > > as....
> > > asblabla
> > >
> > > Because then everything is linked together.
> >
> > I doubt that this is feasible w/ squeak, but in a perfect world, asURL
> > asBlaBla and friends *would* be part of String, but they would also have a
> > module they were associated with; so you could browse methods by class or by
> > module. In theory, module dependencies could be automatically computed,
> > then...
>
Wouldn't these thing be easier if there was sideways relation,
inheritance from several classes ?

Karl

> These things are basically possible.
>
> If you take a chunk of code which represents the most visible bits of functionality of
> some prospective module, you will discover within it usage of certain selectors in certain
> contexts. These can be located, and it is possible to identify these with both their
> usage and their implementations. Do enough of this, and you can probably assign chunks of
> selectors ( call them interfaces if you wish ) to both the module which uses them (
> exclusively, perhaps ) and the classes which have been extended to support such modules.
> I developed just such an analytical capability in Oasis for just this sort of task- it was
> meant to assist in the modularization of lots of non-modular code. When I started it, I
> thought I would be mainly interested in VisualWorks, but since then the same sorts of
> problems have begun to plague Squeak to an even greater extent.
>
> If you do this, then you have knowledge of which selectors are extensions and which are
> intrinsic properties of the various "base" classes. You then "know" more clearly what
> belongs in those "base" classes, and what is fluff- too much fluff is not a good sign.
>
> > It's really powerful to be able to add methods to Object, sometimes; but it
> > would be really neat if you could take those methods *OFF* too :)
>
> If you know which ones they are, this is trivial.
>
> - les

[Richard A. O'Keefe]

Paul Fernhout <***@kurtz-fernhout.com> wrote:
The argument "novices to Squeak and Smalltalk need everything in one
image to see the power of Squeak" which has been made in the past as
justifying big images is not good enough one for burdening everyone else
with such an image.

This sounds like a response to a misunderstanding of something I wrote.

Let's face it, for beginners there is *no* difference between a system
with a large library that is loaded (Squeak) and a system with a large
library that is not loaded (Java), except that the former is easier to
navigate in and doesn't require setting up a CLASSPATH. I have been
reading about Java and thinking about Java since Java 0.9, and I find
the Java libraries overwhelming.

"to see the power of Squeak" has never as far as I know been an issue.
FINDING USEFUL CODE has been. FINDING HELPFUL EXAMPLES has been.
I have learned a lot, and copied a lot, from code I have never used and
never expect to use, or which didn't in fact work (but the bit I copied did).

I think Paul Fernhout and I would both be delighted with a version of
Smalltalk in which there was a small "core" image, with segments automatically
loaded on first use, the division into segments being visible or invisible
in the browser as one chose.

I'd like to have a better understanding of
- who is harmed by the present image size? (what _kinds_ of users)
- how many people are harmed by the present image size?
- how badly are they harmed?
- in what ways are they harmed?
- are there any proposed solutions that would, over-all, do less harm?

For reference purposes, I just did "ps -l -y -u $LOGNAME" on my
Sparc/Solaris 2.8 box, and found

SZ RSS program
16MB 12MB Xsun
17MB 13MB Acrobat reader, displaying a 16-page file
24MB 10MB Squeak 2.7

SZ is the total virtual memory size including kernel resources, I believe.
RSS is the resident memory size, the amount of physical memory actually in use.

It seems fair to say that if you are happy to use Acrobat reader, the size of
Squeak 2.7 should not worry you either. Squeak 3.0 added about another 3.2 MB
to the image size. It's fair to say that it would STILL be less than Acrobat
reader. (Which invites the obvious question: "what the heck is Acrobat doing
with all that memory?") Squeak 3.0 on a PowerMac wants 20MB, but I would
expect the average sessions to need only about 12MB in its resident working
set, if that. ("About This Computer" says that Squeak 3.0 is _using_ 19.6MB;
but that's SZ, not RSS.)

While I affirm that Squeak's size is not out of line, compared with other
programs and language implementation, there are many other reasons to want
modularity. For me at least, Squeak falls over as often as Windows, and
modularity should help with that.

[Karl Ramberg]

Mark Guzdial wrote:
>
> Yeah, it's a student in the current Squeak class. There is a lot of
> grumbling in that class this term. We may have required use of the
> MPEG support a little early for such a large (240) class of Squeak
> novices. (See the assignment definition at
> http://coweb.cc.gatech.edu/cs2340/1057.

Looks like a really fun assigment. Sign me up :-)

Karl

[Glyph Lefkowitz]

On Thursday 19 April 2001 08:45, Paul Fernhout wrote:

> I enjoyed your write up. It takes a certain set of skills to be able to
> produce such a detailed and well written set of issues from a first-hand
> perspective, and thanks for doing it.

And thank you for reading and responding! I was quite nervous to be posting
a draft of something critical so early in my squeaking career, but it seems
presently topical so I didn't want to miss the opportunity. Happy to see
that the community is so friendly and erudite :).

> You get pretty much complete agreement from me.

Glad to hear that too.

> [much stuff elided]

> Manual De Landa in his book "A Thousand Years of Non-Linear History"
> talks about "hierarchy" and "mesh-works" as two organizational forces
> that are always intertwining on a practical basis. The problem we have
> here is a basic difference in slant from SqueakC and developers coming
> from a Unix (or commercial) background. The original Smalltalkers must
> believe in mesh-works, but we are saying Squeak needs a bit more
> hierarchy. The reality is probably that something in the middle is a
> better thing than being at either extreme.

It seems to me that the heirarchical organization of a UNIX installation is
more of an issue from a technical perspective than a social perspective. In
the case of Linux, Linus manages the core but does practically nothing to
dictate policy even to a group as system-level as the XF86 people, since they
are working to a more-or-less specified standard of UNIX, and their code
works on FreeBSD too.

Whereas Squeak is a mesh-work in terms of its internal organization, but
socially, it is currently a very strong heirarchy with SqC at the top. The
absence of modularity (heirarchy?) in the code doesn't permit anyone to make
changes that will continue to work with other people's work in the future
without SqC's approval. It seems that revolution is brewing around the
Squeak World Tour, but without some sort of modularity being included in
their plans, it would just be 2 heirarchies.

> > However, making the virtual machine modular, adding namespaces,
> > fixing the UI [etc] is a difficult, but eminently possible task.
>
> Agreed. Having pluggable primitives is already there to an extent
> (yahoo!) as a nod to modularity, but the deeper issues of modularity

As a matter of fact, what convinced me to stick with Squeak was browsing
through the FFI examples :).

> (vm-to-vm remote debugging),

How far in that direction does Nebraska get us already?

> namespaces,

Environment already does this to some extent, right?

> and alternative "classic" GUI

There were GTK bindings at some point (again, broken by evolution of the
interface) but how hard would it be to get them working again, this time
using the modular FFI?

Less extreme, and more portable: a modification of the virtual machine that
would allow multiple toplevel "native" windows to be created would make a
more normal-looking UI quickly possible.

> > The problems I've enumerated here are some of the things I hope
> > to work on as I work with Squeak.
>
> You and many other people!

Well, let's get together then! :)

> There needs to be a group that has a mainline distribution with an emphasis
> of addressing these issues. (SqueakFoundation?)

I believe this is what the Squeak World Tour is doing, right? I would like
to contribute to a group doing this as soon as possible. How do I sign up?

> My prediction is that within a year if a fork happened and took off,

My prediction is that such a fork *will* happen. Although I'm no expert in
smalltalk yet, I will do my best to help make it happen if SqueakC doesn't
make modularity and some sort of "baseline" API beyond ST-80 a high priority.

> no one will want the SqueakC distribution,

Certainly nobody will want their (monolithic) distribution, but everyone will
want their features. Despite the problems we're discussing, there are a
number of terribly smart people working on adding some great things to squeak
at SqC. Pressure for them to modularize such features would be nothing but
good, IMHO.

> But there is a high cost for everyone to pay [...]

Not as high as the cost that has been paid, and will continue to be paid, by
the development community in terms of lost interest and continued bad press.

> [ snip stuff about apple and IBM ]

Your suggestions would involve a corporate entity behaving rationally, so
I've got to discount them as whimsy. :)

> However, the essential thing to remember is the most important aspect of
> Squeak is the community and this mailing list. If we all "burned the
> disk packs" I'm sure this crowd could have a better Squeak up and
> running in six months! (Probably with protoypes like Self.) Whatever is
> done, I think an essential aspect of any effort has to be to keep the
> Squeak community strong and growing.

It is indeed unfortunate that a fork is necessary, but let's thank the magic
of Open Source that a fork is possible! It certainly wouldn't be possible to
accomplish such a thing with VisualWorks.

--
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
http://twistedmatrix.com/users/glyph

[Mark Guzdial]

>
>By the way, adding better documentation (with examples) to the system
>might make excellent class projects at GATech by the way... If I still
>taught programming these days I'd try to make as many exercises as
>possible be a contribution (no matter how minor) to some open source
>effort (even if the students decide not to contribute it after it was
>done) as a way to learn by doing and show them the larger context of
>their programming efforts. How about telling that student he or she will
>get an A in the class if she or he writes good documentation to some
>number of classes or methods found confusing? Just think what 240
>students working together could add in just one week near the end of the
>semester!
>
>-Paul Fernhout
>Kurtz-Fernhout Software

We do this, in a sense. Visit
http://coweb.cc.gatech.edu/cs2340/Cases -- there are over 100
well-documented projects here for future students to use as examples.
Students get extra credit for doing this. Several of these ARE
tutorials and other forms of documentation.

When you look over these, you'll also see that the MP3/MIDI player is
*NOT* the hardest project we've given students in this class. A year
ago, students built personal newspapers that scoured a dozen websites
to create HTML and PostScript personalized newspapers, with pictures.
It's not the COMPLEXITY of the project that students are grousing
about (well, it is :-) -- we should've waited a term until the MP3
plugin was better shaken-out.

Mark

--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
Associate Professor - Learning Sciences & Technologies.
Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/
[phone] : Fax [phone] : ***@cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

[Paul Fernhout]

Mark Guzdial wrote:
> We do this, in a sense. Visit
> http://coweb.cc.gatech.edu/cs2340/Cases -- there are over 100
> well-documented projects here for future students to use as examples.
> Students get extra credit for doing this. Several of these ARE
> tutorials and other forms of documentation.

Looks like a lot of great stuff!

However, I'm not sure what the licensing status of these or the related
code is. It is unfortunate that most people who develop intellectual
property (ugly word) have so little conception of the legal and social
implications of that. Getting the students to think through the
licensing issues and the implications might be a good learning
experience (even if perhaps many CS programs might typically avoid
teaching this). It seems like every creative person should take a course
on intellectual property law (at least to know the basics and when to
consult a lawyer etc.) to be better able to ensure their creations
prosper as they wish them to.

On that note, anything the students could do that could become part of
the community code and documentation base (i.e. put contributions under
the Squeak license or a specific compatible license like BSD etc.) might
be of value to the students, giving them a sense of pride in an
accomplishment that was publically recognized. [Obviously, it would be
controversial and perhaps counterproductive to demand the students
actually release under a license, although I think most might release
something once it was finished.] That would help them learn to be part
of a larger effort and also think about the meaining of getting their
stuff to be used (no matter how small the contribution). Obviously what
the community needs might be different than the sensible way to teach
about basic concepts, but maybe there are some matches in there
somewhere (dcumenting basic classes etc.). And also obviously, too many
students unleashed on a open-software community might create a burden
for that community. Still, this indirectly adds a sort of apprenticeship
model to learning to program in Sqeuak, and there might be some value in
that.

Perhaps we as a community need a fine grained way of listing issues that
students (apprentices) could just pick up and respond to (i.e. we need a
comment for class XYZ that is under the Squeak license, or we need a
class that does XYZ that is under the Squeak or a compatible open soruce
license, or wouldn't it be nice if this bug was fixed under the Squeak
license?) Perhaps there is another issue here -- a bug or enhancement
tracking system (beyond this list) that students and faculty could
consult for immediately relevant class projects, combined with a way of
tracking the licensing status of contributions.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

[Alan Kay]

Jerry --

At 8:13 AM -0600 4/19/01, Jerry Jackson wrote:
> >
>> The only IDEs better than Squeak's are in other Smalltalk's, in my
>> opinion. I took a liking to VisualAge for Smalltalk during
>> my internship
>> at Progressive, and was a little bit annoyed by Squeak when I
>> would come
>> home and be using it, rather than VAST. But then school
>> started, and I
>> was back to XEmacs. I figured that there had to be something
>> better for
>> C++ and Java.
>>
>
>The Squeak IDE is definitely tops of anything I've seen in a long time. In
>fact, it's
>eerily reminiscent of the Interlisp-D environment (which I still routinely
>annoy co-workers by raving about -- usually during the denigration of some
>ugly wart in a current IDE).

Guess where the Interlisp-D environment came from ..... and when ...
and what code was used to do its window system .....

Cheers,

Alan

[Paul Fernhout]

(replying to other comments in this thread) Personally, I still like
reading Slashdot. It may have a problem with signal-to-noise sometimes,
but you can always browse at +2 or higher to eliminate much of the
clutter. Considering how Slashdot readers might come look at this list,
we might want to be a bit more broadminded.

In the case of this post, I think the student had numerous good points
that Squeak should address. (Obviously the student and I might disagree
about the value of the Smalltalk keyword syntax which I love and
consider a real strength of the language -- now, if I could just merge
it with Python's indentational significance which I also love.) In part,
this is exactly what Tom in "Re: Announcing to the world.." was
concerned about -- the rough edges of Squeak make it unpleasant for many
people to pick up -- especially people used to other systems. Because
Squeak does not clearly win in every category(e.g. modularity, speed) it
becomes a "compromise" to use it -- not a "no brainer".

Here are some substantial issues raised by the student with my
elaborations:

The student wrote:
> The Squeak IDE is one of the most frustrating pieces of software
> I've ever had to use.

I've taught computer programming to biology majors for several
semesters, and I've definitely learned that the "listen to your users
but ignore what they say" applies equally for students giving feedback
on a course. Yet, if someone points something out, there probably is an
issue somewhere.

This frustration could come from several reasons (MP3 support was
mentioned) but I know there are deeper issues with Squeak, as the
student goes on to point out.

There are numerous typical issues learning Smalltalk as well which may
have arisen if the instructor was coming from Scheme (a fine language --
check out DrScheme.)

LearningWorks attempts to address some of them -- principally that it is
difficult to know what is important in the image (a recent post to this
list raised this as well). They have made changes to the browser and
debugger to hide unnecessary complexity for a particular learning
exercise.

Also, because there are no firewalls in the sense of having development
tools in one VM talking to an application in another via remote
debugging (as is now common under say VC++ or some Python development
tools) it is difficult to experiment with the core of the system.

> Slow,

Very true, depending on your machine. I'd like to know what version and
machine the student used. Squeak Version 3.0 is near unusable on the
180-Mh PPro NT system I use. Yes, my machine is behind the times, but
Squeak1.13 under MVC was much snappier, and I use other OO systems on
that machine with various GUIs that work well. Granted in about 10 years
machines will be 1000X faster, and 100000X faster in 20 years, but that
doesn't mean unnecessary waste is a good thing, in part because we want
Squeak then to run on $0.01 machines, which will be same as what I have
now. I think the sluggishness is probably a symptom of design and
implementation issues. I've even heard key Morphic developers have said
on this list it needs an overhaul for various reasons.

Also, the lack of modularity makes it hard to put in place an
alternative faster GUI. Why not just use an earlier version? Because
only 3.0 (2.9?) was trying hard to be event driven and have that support
in the VM. Lack of events meant lost clicks and such which is
frustrating in earlier versions (and makes Squeak unsuitable for user in
a shippable application because I know users won't put up with any
significant number of lost clicks these days.).

> ugly as sin (both the original MVC and the newer Morphic GUI),

Obviously this is a matter of choice. But MVC is not the pretty out of
the box (although it could be in theory). And Morphic, while it looks
better, still has IMHO issues with how the development process (e.g.
handles) integrates with the pretty look (though handles look nicer in
3.0).

> and bloated as all hell.

Right on. We've gone from a base system that was several megabytes to
one that is about twenty. There are endless extra classes in the system
contributing to learner confusion. Again, this stems in large part from
lack of modularity. GNU Smalltalk for example has a package loading
system and ships with a small core -- why can't Squeak?


> But good luck trying to turn it into a binary to
> distribute to your friends, because you can't!

Absolutely correct. And this is a big issue for many people. There is no
one click make an EXE. You can ship the entire system but for hello
world or a text manipulation program it takes up way too much space
(again lack of modularity) and there is more than one file that need to
go (at least the EXE and the image) and in the minimal case you will get
complaints on startup. Obviously Perl and Python have this issue too
(although Python can be "frozen" into an EXE with a script).

And don't ask them to try and learn the language either, because there's
no documented API, and the purportedly self-commented code really isn't.

> Did I mention that that same code sometimes breaks on you,
> fresh from an install? Yep, believe it.

Wouldn't surprise me too much, given the lack of modularity. Well,
actually it would if what the student did was identical from a base
image, but I'd accept that it happens (perhaps for subtle reasons the
student does not notice like load order). Again, there is a flaw in the
approach somewhere that this can be perceived to be happening.

Obviously it is stinging to everyone involved with Squeak to get remarks
like these (after 4+ years since release) but these issues raised do
exist and they are one reason Squeak has been less successful than it
will be. (Personally I'd like nothing more than to fix all these
shortcomings if I could find the time.)

I think one reason these problems persist is that SqueakC wants to
create a development environment for children and novices (who just stay
in Morphic and maybe do some scripting, as their examples show, and they
have accomplished amazing things as the Morphic 3.0 car demo shows) and
Squeak is good enough now for those sorts of apps (especially sicne they
control the mainline that is "supported" in the sense of being rolled
forward).

I want a development environment for the power programmer, and perhaps
so does that student, and Squeak still lacks in many of those areas (as
useable as Squeak is for someone willing to put up with its limitations
and use it for the things that Squeak does well right now).

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

Ned Konz wrote:
>
> On Wednesday 18 April 2001 07:21, Wouter Gazendam wrote:
> > Might be an interesting advocacy:
> > http://slashdot.org/article.pl?sid=01/04/18/001236&mode=thread
> >
> > Wouter
>
> There's an interesting response from a Georgia Tech student (one of Mark
> G's?):
> http://slashdot.org/comments.pl?sid=01/04/18/001236&threshold=1&commentsort=0&mode=thread&pid=52#60
>
> The overall tone is summed up by:
>
> "Squeak has been the worst programming language I've ever had to deal with
> (out of the seven or eight I've learned).
> The Squeak IDE is one of the most frustrating pieces of software I've ever
> had to use."
>
> But (s)he goes on to describe why.
>
> --
> Ned Konz
> currently: Stanwood, WA
> email: ***@bike-nomad.com
> homepage: http://bike-nomad.com

[Ned Konz]

On Wednesday 18 April 2001 18:10, Paul Fernhout wrote:
>
> Also, the lack of modularity makes it hard to put in place an
> alternative faster GUI.

That isn't my impression; it seems like when you enter a Project you can do
more or less anything you want (perhaps by subclassing Project or changing
its logic).

There's nothing magical about the Morphic event loop; you could do this in
your own UI as easily. The Input Process keeps running, and you can just get
events off the queue.

Of course, if there were a real hierarchy of Project types (MorphicProject,
MVCProject, FabrikProject, etc.) it would be easier (yes, I guess this is
modularity).

And you wouldn't be able to use any of the tools in your new UI (at least not
easily).

But for a consumer device or standalone app, this might be fine.

--
Ned Konz
currently: Stanwood, WA
email: ***@bike-nomad.com
homepage: http://bike-nomad.com

[Paul Fernhout]

(from another part of the thread)
Thanks for the kind words Adam.

Replying to yourself is bad form, but Paul Fernhout apparently wrote:
> And don't ask them to try and learn the language either,
> because there's no documented API, and the purportedly
> self-commented code really isn't.

Actually, the student wrote the above (my mistake in letting it slip by
looking like I wrote it). I was too in too much of a hurry to run
downstairs to see "Star Trek Voyager" which has just started that I
didn't proofread enough before sending.

But to respond to the student's point (which was my intent), there has
been in the past a lack of comments on many key classes in Squeak. Also,
it's not always clear where to look for comments (unlike say with
JavaDoc where you get an entire web page to view at once with important
comments covering a class). I personally like having a "documentation"
method rather than have to press a special button to be in documentation
viewing mode.

Someone suggested months a while back on the list being able to include
a comment in the class definition -- I like that idea a lot, as opposed
to always reformatting that entry. Also, Smalltalk could have benefited
from a triple quote like Python so that larger example code snippets
quotes can be easily pasted into regular code, as opposed to being
tempted to invent another place in he Browser to put them where code and
comments can be mixed without needing to be compileable. In general,
anything along the lines of literate programming support (mixing code
and explanation) would be nice.

Squeak has some of this (with picking fonts etc.) and I haven't explored
this as much as I could, so perhaps more can be done already than I have
tried. In general, I like sticking with unadorned text though. It would
be great to be able to mix in XML into code too I guess (a fusion of
code and data -- say for defining window layouts), but this starts down
a more general path for embedding various types of textual
representations, with say embeddable Scheme or Forth mixed with
commentary and Smalltalk and XML and so forth, all happily digested by
various compilers invoked on a fragment by fragment basis.

I disagree somewhat with the student about the self-documenting nature
of typical Smalltalk code, but then again I earlier disagreed over the
value of the keyword syntax. I do however think that complaints about
lack of being self-documenting may have something to do with the excess
complexity of the base system. For example, whenever I try to wander
through Morphic base classes my head starts spinning -- no matter how
well the methods are documented. Because Morphic wants to be prototype
based (coming from Self), it needs extra baggage to fit into Smalltalk
just for a start. But it needs refactoring too, and maybe some trimming
(dropping delegation like aspects in the base for example).

Protocols are not used consistently in this and other Smalltalks. I
personally like using "ing" words for categories preferring for example
"intializing-releasing" over "intialize-release", but I have to also
deal with a preexisting inconsistent naming convention. Unlike
VisualWorks, Squeak doesn't attempt to track protocols to keep you in
the same one as you move around in a browser. That is, in the default
3.0 release if you are in "intialize-release" and jump to another class
the Browser doesn't put you in the same protocol (and ideally select the
same method). And the standard browser in Squeak doesn't remember the
last protocol you were in in and old class to suggest the name for a new
one either.

Changes have been happening so rapidly over the past few months and
there never was a stable base GUI (beyond the too limited MVC). So I can
see how a student would be concerned about there not being a documented
API (in the sense of a book or help file or HTML overview) when it comes
to things like GUI widgets. There is some material on the web, but
obviously you need to match the documentation with the version of
Squeak. Since historically Smalltalks have had minor incompatabilities
in various classes (ANSI anyone?) I can see how these could throw a
student trying to learn from a published reference on Smalltalk (no
matter what Smalltalk). So, Squeak for students could benefit by being
more self-contained in this sense, and it obviously isn't quite there
yet. However, I'm not up to date on what introductory material is out
there on the web, so there may be great resources that didn't connect
with this particular student for whatever reason.

However, in Smalltalk and Squeak's defense, one reason I love Smalltalk
is because the source has been available as a reference in most
versions. When I do Java or Python or Scheme I am always consulting
printed or HTML references or going to Google or DejaNews (now the
same), whereas in Smalltalk I would be looking more in the image. Why
just today I was trying to post a menu event in Java (pays the bills,
sigh) and even with Google and the API documentation I couldn't figure
out how to do it properly in non-deprecated form in the short time I had
to devote to that (even after looking at all the API calls and classes
likely to be involved), so I gave up on that approach and solved the
problem another way. In any Smalltalk system I probably would have had
little difficulty understanding how to do that because I could see how
it was done by the system.

Having said that, I had to approach Smalltalk several times on several
different occasions on several different platforms (Mac/APDA, Tektronix,
ObjectWorks, ST-V/286) before I started to feel comfortable with it, and
that was mostly after already knowing something about OO from
programming on a Symbolics and on the Mac. Just like the first time I
got a Unix account (~1982) I didn't really "get" hierarchical
directories or understand where things were, and only really "got" them
and the layout of Unix when months later I remembered I had the account
and played around with it some more.

Fifteen years ago I read the results of a survey that concluded the only
thing all excellent Unix system administrators had in common was knowing
how to use the "man" command. One of the reasons Smalltalk testing (for
jobs) is somewhat of a joke is that one of the most important skills of
a Smalltalk developer is someone who can learn how to do things using
the Smalltalk Browser, and that doesn't show up in a paper and pencil
(or online) test.

But having said that, obviously the classic problem for a Smalltalk
novice is not knowing where to start, and a more modular base system
with more commented base classes with dynamically loadable examples
running on a stable GUI would help.

I can very much imagine how a student (especially with other courses
etc. in a tough school like GATech) could easily feel overwhelmed having
to jump into using the best of all Smalltalk systems. It has been said
it takes six months for full-time employees (with a background in say
COBOL) to come up to speed in Smalltalk and the typical class libraries.
In the context of a student doing Smalltalk part-time for a semester,
any obvious warts like missing documentation or slow or buggy systems is
going to be a lightning rod for disgruntlement. The bottom line is that
Squeak has good points and bad points, and we as developers must see
them both. We can't pretend the limitations don't exist, because
recognizing them and remedying them is the only way things will get
better.

One issue specific to the situation seems that the course sounded
ambitious -- doing MP3 plugins and handling 240(!) students -- as
opposed to just simple graphics or sounds within the system for a class
of thirty. It's an indication of Squeak's previous success at GATech
that it has grown to this scale. I personally can't imagine what it
would be like to teach Squeak to 240 people at once -- I had my hands
full trying to teach 20 biology majors the rudiments of C/C++ (I found
the ones who didn't learn on their own learned the most when I spent
time with them hands-on in the computer lab to help them over rough
spots, something that won't happen as much in a class that size). Not
knowing the course or the instructor or the student (although Mark
Guzdial mentions equipment & software issues and an instructor new to
Squeak) I can't know exactly what produced the strong negative reaction.
Not every college course can be a great success for everyone, especially
if the instructor has the guts to take risks and try new things. Still,
I feel that despite all its good points (e.g. Mark drawing "oohs" years
ago from GATech students by showing them how to draw a line across and
outside a window), Squeak was undoubtedly partly at fault, lacking for
example complexity management features like those LearningWorks has
sought to add.

But who knows, with another few weeks in this semester, maybe this
student will change his or her mind, like I did about the value of
hierarchical directories. In any case, school is about learning, and
learning to deal with frustrating technical glitches, poor
documentation, unfairness and so forth while staying pleasant(*) is
(sadly) probably good experience for life. Obviously though, that isn't
what we want the main thrust of Squeak to be about.

By the way, adding better documentation (with examples) to the system
might make excellent class projects at GATech by the way... If I still
taught programming these days I'd try to make as many exercises as
possible be a contribution (no matter how minor) to some open source
effort (even if the students decide not to contribute it after it was
done) as a way to learn by doing and show them the larger context of
their programming efforts. How about telling that student he or she will
get an A in the class if she or he writes good documentation to some
number of classes or methods found confusing? Just think what 240
students working together could add in just one week near the end of the
semester!

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

(*) A quote from the movie "Harvey": "There are two ways to succeed in
life: to be awfully clever, or awfully nice. I've tried clever; I prefer
nice."

[Simon Michael]

(oops, you asked this on the list. FWIW:)

Doug Way <***@riskmetrics.com> writes:
> I'm probably missing something obvious, but how are these levels

Hi Doug,

off the top of my head: the moderators are a rotating group chosen
semi-randomly from the membership. There is a scoring system called
"slashdot karma" which tries to weight this towards more active and
respected posters. If you create an account and use the site for a
while, every now and then you'll be allocated 5 karma points to use
for moderating comments as you see fit.

there is also meta-moderation -

"What follows is 10 random moderations performed on comments in the
last few weeks on Slashdot. You are asked to honestly evaluate the
actions of the moderator of each comment. Moderators who are ranked
poorly will cease to be eligible for moderator access in the future."

more at http://slashdot.org/faq/

-Simon

[Bob Hartwig]

Oh man, this started out my day with a laugh, thanks. The pro-Smalltalk
posts came across as genuine and informed, the negative ones came across as
trolls. Reasonable people who read these posts will be intrigued, while
the typical Slashdot weenie will go away with his worldview validated,
content to jump through hoops for another day.

The only potentially damaging post was the one by the GA Tech guy, who
actually *used* Squeak and ranted about how much he hated it. On the other
hand, I finally have an explanation for all of those GA Tech Squeakers who
kept complaining that they couldn't get SqueakAmp working. :)

-Bob

BTW John, my condolences to your server.


At 04:21 PM 4/18/2001 +0200, you wrote:
>Might be an interesting advocacy:
>http://slashdot.org/article.pl?sid=01/04/18/001236&mode=thread
>
>Wouter
>
>

[Ned Konz]

On Wednesday 18 April 2001 07:21, Wouter Gazendam wrote:
> Might be an interesting advocacy:
> http://slashdot.org/article.pl?sid=01/04/18/001236&mode=thread
>
> Wouter

There's an interesting response from a Georgia Tech student (one of Mark
G's?):

http://slashdot.org/comments.pl?sid=01/04/18/001236&threshold=1&commentsort=0&mode=thread&pid=52#60

The overall tone is summed up by:

"Squeak has been the worst programming language I've ever had to deal with
(out of the seven or eight I've learned).
The Squeak IDE is one of the most frustrating pieces of software I've ever
had to use."

But (s)he goes on to describe why.

--
Ned Konz
currently: Stanwood, WA
email: ***@bike-nomad.com
homepage: http://bike-nomad.com

[Simon Michael]

Yes that's one of the interesting posts so far.

In a case like this, typically I would expect to see a +5 clarifying
followup before too long, assuming 1. the issue can be clarified! and
2. sufficiently high mass of squeak insight + posting energy in the
community.

[Richard A. O'Keefe]

The student wrote:
>>> The Squeak IDE is one of the most frustrating pieces of software
>>> I've ever had to use.

Compared with what, I wonder? I've been using computers since 1974
and GUIs since 1984. Windows gives me screaming fits from frustration.
MacOS makes sense, but Inside Macintosh made Squeak documentation look
good. Metrowerks is a pain. I once spent a couple of hours trying to
write Hello World in IBM's Visual Age for C++ and failed. (Maybe a
printed manual would have helped...) I use Sun's Workshop moderately
frequently.

I have to say that the Squeak IDE is a *dream* for a programmer to use.
Oh, I've got a list of about half a dozen things I'd like, but the
Refactoring Browser does most of them (judging from the description),
and when I finally decide I want them badly enough I'll write them myself.
(Like I now have a "Preferences makeHaloIconsLetters" method that puts
letters in the handles. Needs a bit of tweaking before I could think of
releasing it, but works well enough to satisfy me.)

Of course, it helps to have the old coloured books and LaLonde&thingy
and to be willing to try something new...

The student also wrote:
>>> and bloated as all hell.
to which Paul Fernhout replied:
>> Right on. We've gone from a base system that was several megabytes to
>> one that is about twenty. There are endless extra classes in the system
>> contributing to learner confusion.
and Bijan Parsia responded:
> And excitement! I kinda *like* having a big system. I like bouncing
> around.

What is "Bloat"? I would say that a piece of software is bloated if it
does in 1MB what could be done in 2KB. I would NOT say that a piece of
software is bloated simply because it takes a lot of space; perhaps the
space is used to good effect to provide useful services.

Squeak 3.0.1 has a 9MB image file. Nine, not twenty. Hey, 55% of the
bloat trimmed away with a single glance!

Using MajorShrinkFor3.0.cs, the image can be slimmed down to 888K.
(I know because I tried it.) The VM and shrunk image together come to
less than 2MB. I don't call that bloated.

So what we *actually* have in Squeak is a compact core (by today's standards)
plus about 8MB of compiled library code.

Is an 8MB library "bloat"? Well, compared with *what*?

How about Java? The 1.2 JDK for Sparc/Solaris has (and I have just
measured this) 10.5MB of .class files packed up in .jars. This
corresponds to 20.6MB of sources in /usr/java1.2/src.jar.

The 3.4 release of Quintus Prolog takes 41MB of disc space.
About 0.5MB for the Emacs interface (call it the IDE),
7.2 MB of documentation in Postscript form, 0.8 MB of demos,
2.6 MB of documentation in plain text form, 1.2 MB "VM",
4.3 MB of library, 5.1MB "image", 3.3 MB GUI toolkit (including
on-line help and demos), other stuff, including a non-Emacs GUI IDE.

SICStus Prolog 3.8.4: 100MB of disc. (Also includes book-size documentation
in several formats.)
clisp-2000-03-06 (unpacked but not installed): 18 MB of disc.
Clean 1.3 (lazy functional, Haskellish): 12 MB of disc.
Erlang 4.7.1 (includes copious documentation in several formats): 189 MB.

Nope, Squeak is about the usual size for a freely available programming
language and environment. It could still be bloated, IF a significant
fraction of the stuff in the library were useless or redundant.

There's a lot of stuff in Squeak that's irrelevant to *me*, but every time
I start thinking "this is bloat" I think of a past student who would have
been given a big leg up in a project if they had known about it.

Bijan Parsia wrote:
> Not to say that slim is bad, but sometimes big is beautiful :)

Size shmize. A 1MB program can be bloated. An 8MB program can be slim.
What matters is whether what you get is worth the disc/memory you pay for it.

There's an important difference between something like Erlang (free
concurrent/distributed functional programming language with a large
Open Telecom Platform library including things like CORBA, ASN.1, SNMP,
Web Server, GUI kit, replicated distributed database (not interface,
implementation), and Squeak. That's the programming environment.
Erlang software is made of modules, and the system doesn't know anything
about a module until it's loaded, so you can't use "reflective" tools
to *find* modules. You have to rely on PDF, HTML, or UNIX man-page
documentation, and poking around with Emacs.

Putting everything in the Squeak image *adds value for BEGINNERS*
because everything is findable.

[Tom]

On Thu, Apr 19, 2001 at 01:03:21AM -0500, Aaron J Reichow wrote:
> I've not foudn anything close. I've looked at oo-browser (for XEmacs), [...]
> All annoying, clunky, slow.

Sorry for stepping on a soap box, but when applied to Emacs, I think
these comments are a bit simplistic. I think people taking a casual
look at Emacs (which may mean "try using it for just a year") often
overlook what has made Emacs the most successful programming environment
ever.

Learning Emacs is a lot of work. There are hundreds of key combinations,
and to new users windows seem to come and go haphazardly. If you want
to use any one of its packages, you first have to figure out how to
load it and configure it. But there is sense in the key bindings and
window management: they show you relevant information quickly and without
needing to interrupt your flow of work. And the configuration options
generally are things people need and want to configure.

In terms of functionality, there is a huge number of powerful packages
for Emacs. When used with languages like Lisp (and Smalltalk, if anybody
wrote the interface), Emacs can give you much of the same information
as Smalltalk (browse callers, show uses, go to definition, etc.).
GNUS, RMAIL, and VM are still some of the most powerful and featureful
news and mail readers around, and they had add-ons for collaborative
filtering, relevance feedback, MIME, and automatic display of contextual
information long before those things became hot research topics.
Emacs is still used a lot for research in new UI functionality.
Its file manager (DIRED) is probably still the most effective file
management tool around. There are a huge number of packages for all
sorts of other things, including web browsing, telnet, and terminal
emulations. Emacs's integration with a wide variety of programming
languages (including layout) and development systems means you can
develop a whole mixed language system (Lisp, C, ...) from within a single,
consistent environment.

On UNIX, Emacs is an odd hybrid, coming with its own Lisp interpreter and
running in its own process. But it's small and fast by modern standards
and it has learned to integrate and live well in its new surroundings.
On the Lisp machine, its second home after the DEC-10, Emacs integrated
as well out of the box with Lisp as the Squeak browsers integrate with
Squeak and provided similar functionality.

Of course, there are plenty of things wrong with Emacs. Foremost,
its lack of multithreading, its lack of any kind of widget set,
its messy internal organization, and its lack of widespread support
for OOP. And its learning curve is so steep that many people give up
before they get to really know it.

In any case, I am not suggesting that Squeak should adopt anything
in particular from Emacs. But I think it's unwise to dismiss it as
"annoying, clunky, slow". While very different from Smalltalk, Emacs is
the other great programming development environment; take it seriously.
And just like Emacs has learned something from Smalltalk environments,
there is some stuff to learn from Emacs.

Cheers,
Thomas.

[Paul Fernhout]

"Richard A. O'Keefe" wrote:
>
> The student wrote:
> >>> The Squeak IDE is one of the most frustrating pieces of software
> >>> I've ever had to use.
>
> Compared with what, I wonder?

We're talking about two things, GUI building and development tools. As
far as building a window goes, I find Delphi or VisualWorks easier to
use. As far as browsing code, I'd agree almsot any Smalltalk system is
better than what the rest of the world has (especially when you have
ENVY).

> What is "Bloat"? I would say that a piece of software is bloated if it
> does in 1MB what could be done in 2KB. I would NOT say that a piece of
> software is bloated simply because it takes a lot of space; perhaps the
> space is used to good effect to provide useful services.
>
> Squeak 3.0.1 has a 9MB image file. Nine, not twenty. Hey, 55% of the
> bloat trimmed away with a single glance!

Squeak 3.0 is 24.8 MB on my NT system. There is also the issue of the
sources and changes files... The image file is not intended to stand
alone, even if it can.

> Using MajorShrinkFor3.0.cs, the image can be slimmed down to 888K.
> (I know because I tried it.) The VM and shrunk image together come to
> less than 2MB. I don't call that bloated.

If you are using a verison of Squeak where shrinks works properly out of
the box (modularity again!) or have time to understand a lot of code you
just want to get rid of anyway. However, this can be a PITA when it
doesn't work properly the first time. It also imposes a testing burder
(full testing both before and after stripping). Example, I can almost
guarantee you without having looked at it that the majorShrinked package
you generated will generate walkbacks (due to the shrinking).

> So what we *actually* have in Squeak is a compact core (by today's standards)
> plus about 8MB of compiled library code.
>
> Is an 8MB library "bloat"? Well, compared with *what*?

The other examples you cite are big, agreed. I would never defend Java
as being compact. In my mind, the reference is Forth, where 64K of
source and binary goes a long way (although most Forth distributions
with GUIs top a couple of megabytes).

I think "bloat" == "extra things I don't want right now". I don't want
Morphic for example (as much as I like many of the basic ideas and think
those have potential, if integrated with a permission structure) so for
me Morphic is "bloat". Having to remove something I don't want to be
there in the first place which is taking up lots of resources (say if I
want to just do text file manipulation) is an unneccesary burden.

> Erlang software is made of modules, and the system doesn't know anything
> about a module until it's loaded, so you can't use "reflective" tools
> to *find* modules. You have to rely on PDF, HTML, or UNIX man-page
> documentation, and poking around with Emacs.

True, but having to look at an on-line directory on in Google for an
available interesting module or example hasn't ever really bothered me.

> Putting everything in the Squeak image *adds value for BEGINNERS*
> because everything is findable.

True to an extent, but it also adds clutter which can confuse a
beginner. It also raises the image stripping problem. I still think
loading modules on demand is better way to go in the long run.

Again, as I said in another post on this topic, we need both "mesh-work"
and "hierarchy" in Squeak. What might satisfy us both is a small core
available locally and an easy way to browse modules (and their code) on
a server remotely, with a clear way to know what module you were looking
at or had loaded, with easy loading on demand of something specifically
asked for, protected in such a way that you can only change a module if
you demonstrate somehow you really want to change it. Squeak is so close
to that (aside from permissions) -- except for the persistent naggin
thought such changes (e.g. making a small image as the core) would get
swept away as the SqueakC mainline roles on.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com

[Mark Guzdial]

Yeah, it's a student in the current Squeak class. There is a lot of
grumbling in that class this term. We may have required use of the
MPEG support a little early for such a large (240) class of Squeak
novices. (See the assignment definition at
http://coweb.cc.gatech.edu/cs2340/1057. Some of the debate is at
http://coweb.cc.gatech.edu/cs2340/1269) The server where the class
Swiki is stored is a Mac which has been as reliable as Minnow this
term, which hasn't helped with the cheery attitude of the students.

Lex Spoon is the head TA in the class, and he will be teaching the
class this Summer. I'll be teaching it again next Fall and Spring
2002. This term's instructor is a Scheme-r who's trying out Squeak by
teaching this class, and he's a good guy, but the most vocal students
(in the class newsgroup, in the Swiki) aren't buying in at all.

Mark
--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
Associate Professor - Learning Sciences & Technologies.
Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/
[phone] : Fax [phone] : ***@cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

[Wouter Gazendam]

Might be an interesting advocacy:
http://slashdot.org/article.pl?sid=01/04/18/001236&mode=thread

Wouter

[Kevin Fisher]

On Wed, Apr 18, 2001 at 08:45:34AM -0700, Michael Rueger wrote:
>
>
> Wouter Gazendam wrote:
> >
> > Might be an interesting advocacy:
> > http://slashdot.org/article.pl?sid=01/04/18/001236&mode=thread
>
> Oh boy, Tim you where so wrong about the average IQ of the people
> posting there...
> You just can't stop being optimistic, can't you?
> ;-)
>
> Michael


Must...resist..masochistic...urge...to...check..Slashdot...

Is it really that bad? :)

[Simon Michael]

Tim Rowledge <***@sumeru.stanford.edu> writes:
> Michael Rueger <***@acm.org> is widely believed to have written:
>
> > Oh boy, Tim you where so wrong about the average IQ of the people
> > posting there...
> > You just can't stop being optimistic, can't you?
> Sheesh. Even with Andy Greenberg chiming in he couldn't get it up to a
> tolerable level, no matter how heroically he fought.
>
> Ridiculous, don't you think? Slashdot has become the 'National Enquirer'
> of the web world.

I respectfully disagree. The key is to skim it at level 3, 4 or 5.
I'm a long-time slashdotter and still learn a lot there.

[Christopher Sawtell]

On Thursday 19 April 2001 16:41, Doug Way wrote:
> Simon Michael wrote:
> > Tim Rowledge <***@sumeru.stanford.edu> writes:
> > > Ridiculous, don't you think? Slashdot has become the 'National
> > > Enquirer' of the web world.
> >
> > I respectfully disagree. The key is to skim it at level 3, 4 or 5.
> > I'm a long-time slashdotter and still learn a lot there.
>
> I'm probably missing something obvious, but how are these levels assigned
> to postings on Slashdot? Are there moderators? I didn't notice any sort
> of option to let me vote on whether a particular posting was helpful...

It's quite complicated; First you have to have login so that you are a member
of the Slashdot Community, thus getting your name on the displayed home page.
Then you volunteer to be a moderator via customizing your user settings. Next
they give you a whole series of test moderations in order to test that your
judgemant is more or less along the politically correct road. Once that
hurdle has been overcome, you are suddenly let loose on real live moderating.
It is an extreamly time consuming process as one is supposed to read at a
threshold of -1 so you see, read and moderate _absolutely everything_. I did
a shift for a couple of months and then a more active "real life" compelled
me to flag it away. Taken overall it's not onerous, but when your turn comes
up it's a time consuming PITA.

--
Sincerely etc.,

NAME Christopher Sawtell
CELL PHONE [phone]
ICQ UIN 45863470
EMAIL csawtell @ xtra . co . nz
CNOTES ftp://ftp.funet.fi/pub/languages/C/tutorials/sawtell_C.tar.gz

-->> Please refrain from using HTML or WORD attachments in e-mails to me <<--

[Tim Rowledge]

Michael Rueger <***@acm.org> is widely believed to have written:

> > http://slashdot.org/article.pl?sid=01/04/18/001236&mode=thread
>
> Oh boy, Tim you where so wrong about the average IQ of the people
> posting there...
> You just can't stop being optimistic, can't you?
Sheesh. Even with Andy Greenberg chiming in he couldn't get it up to a
tolerable level, no matter how heroically he fought.

Ridiculous, don't you think? Slashdot has become the 'National Enquirer'
of the web world.

--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
A bug in the code is worth two in the documentation.

[Bijan Parsia]

As is traditional, I shall quibble with some of what Paul says :)

I do so more from a spirit of not being as sure as I infer Paul is in what
I want from Squeak, rather than in the spirit that Paul is dead
wrong. Paul may be dead wrong, but I shant argue that :)

[snip]
> In the case of this post, I think the student had numerous good points
> that Squeak should address.

Paul, I think you're being generous :) I don't think anything would make
that student happy (which is *fine*; there is no tweaking of Perl or C++
which would make me happy with them; I *don't want* to be happy with
them; they should not try to mold themselves to my sweet spot (though, if
there were things they could tweak to make me, if forced to use them,
less miserable, and it wouldn't wreck it for the aficiando's, then I would
request that they be so tweaked).

> (Obviously the student and I might disagree
> about the value of the Smalltalk keyword syntax which I love and
> consider a real strength of the language -- now, if I could just merge
> it with Python's indentational significance which I also love.)

I remind folks of Michael Stark's Golgi work, wherein he had an outline
based code pane. It was very slick. The "turnstiles" followed smalltalks
syntax, such that you might have:

|var1
var2
var3
"the above could be collapsed into the '|' and it didn't need to be
closed"
[self connected
whileTrue:
[self doSomething
self checkSomething
self checkItAgainAndMakeSure
"These would collapse itno the '[', etc."

(Something like that.)


> In part,
> this is exactly what Tom in "Re: Announcing to the world.." was
> concerned about -- the rough edges of Squeak make it unpleasant for many
> people to pick up -- especially people used to other systems. Because
> Squeak does not clearly win in every category(e.g. modularity, speed) it
> becomes a "compromise" to use it -- not a "no brainer".

I think the scare quotes around 'compromise' and 'no brainer' are
important.

> Here are some substantial issues raised by the student with my
> elaborations:
>
> The student wrote:
> > The Squeak IDE is one of the most frustrating pieces of software
> > I've ever had to use.
>
> I've taught computer programming to biology majors for several
> semesters, and I've definitely learned that the "listen to your users
> but ignore what they say" applies equally for students giving feedback
> on a course.

Moreso for students.

[snip]
> > Slow,
>
> Very true, depending on your machine.

Perhaps, more importantly, depending on how you structure your
program. Somethings are easy to write slow, right now. Putting text on the
screen seems to be a big slowdown (e.g., writing to the Transcript). Try
a loop writing each line of a file to the transcript in Squeak and in
Dolphin. *Huge* speed diff.

Of course, Dolphin only runs on Windows ;)

[snip]
> Also, the lack of modularity makes it hard to put in place an
> alternative faster GUI.

Is this true? Right now, nearly the same code works for two radically
different UIs (MVC and Morphic) for nearly all the development tools
(e.g., the PluggableText, etc. classes).

[snip]
> > and bloated as all hell.
>
> Right on. We've gone from a base system that was several megabytes to
> one that is about twenty. There are endless extra classes in the system
> contributing to learner confusion.

And excitement! I kinda *like* having a big system. I like bouncing
around.

No to say that slim is bad, but sometimes big is beautiful :)
[snip]
> > But good luck trying to turn it into a binary to
> > distribute to your friends, because you can't!
>
> Absolutely correct.

No, slightly exaggerated. C'mon. You can pretty easily make it two
files. That's not bad at all. Granted, if you want to share a lil utility,
you may end up in shrinkage hell, but that's a different issue (actually,
that's the priori issue! :))

> And this is a big issue for many people. There is no
> one click make an EXE. You can ship the entire system but for hello
> world or a text manipulation program it takes up way too much space
> (again lack of modularity)

Er..see above :)

> and there is more than one file that need to
> go (at least the EXE and the image) and in the minimal case you will get
> complaints on startup. Obviously Perl and Python have this issue too
> (although Python can be "frozen" into an EXE with a script).

And java, and vb, and....

Not to say that it wouldn't be nice to have it otherwise, but the person
was reaching on this one :)
[snip]
> Obviously it is stinging to everyone involved with Squeak to get remarks
> like these (after 4+ years since release)

Er..well, I'm involved and I don't *feel* stung. The *actual* issues
raised (as opposed to the silliness, "I can't imagine..." "I can't see
how...") are well known and can be showstoppers or minor quirks depending
on a lot of factors.


> but these issues raised do
> exist and they are one reason Squeak has been less successful than it
> will be.

And being less popular (which I think is the real key) that it will be
isn't necessarily a problem ;)

[snip]
> I want a development environment for the power programmer, and perhaps
> so does that student, and Squeak still lacks in many of those areas (as
> useable as Squeak is for someone willing to put up with its limitations
> and use it for the things that Squeak does well right now).
[snip]

Here's an interesting case story:

I've written an irc bot, called the DiaWebLogBot. It's used to publish a
collaborative weblog at http://monkeyfist.com/DailyChurn. Everyone who
uses it loves it. It's a bit slow, the code is ugly, and it doesn't
autoreconnect when my connect flakes out. But *everyone* who uses it,
loves it.

Thus far, it's been cloned twice, once in Python, once in Perl. Neither is
as full featured (well, I've been dorking with it for over a year, so no
surprise), and niether is as easy, imho, to get at the guts.

The python is pretty clean python, so I've been modifying it for a new,
rdf based varient. I'm just totally suffering using IDLE. Scroll up,
scroll down, oops, open another file, scroll up, scroll down, switch
windows, cmd-b...d'oh!, doesn't work. Guess I use find. Oh, got to scroll
to the top of the file. YUCK!

Frigging stack trace drives me nuts. No *sorry*, that code you modified
has nothing to do with the object, start over. YUCK!

Time to hit the docs. Oh *that* module. But I still don't understand the
function! Where's the code. It's in some directory, in some file. Find the
file. Open the file. Scroll up, scroll down. BLARGH!

I'd love to fix this in Python, and it's perfectly possible to do so, if
only I had the time :)

But it *does* very easily run headless on Linux :)

Python 1, Squeak 1? :)

Oh, I also planned to do a bot in Prolog, but there I'll have to do the
irc library from scratch. Uber-blargh!

I intend to backport the Python work back to Squeak. I'm, in the end, not
sure if I actually gained anything by modifying the Python bot (I had
intended to use some modules but, d'oh, they were going to be *hell* to
rip apart sufficently to pop into the bot module. YUCK!)

Does this mean Python sucks? Well, yeah, it probably does ;) But if *I*
were posting to Slashdot, I think I'd mention its strengths, too ;)

But, then again, I wouldn't post to Slashdot :)

Cheers,
Bijan Parsia.

[Richard A. O'Keefe]

Alan Kay <***@disney.com> wrote:
Guess where the Interlisp-D environment came from ..... and when ...
and what code was used to do its window system .....

Having used Interlisp-D (I was lead programmer on Xerox Quintus Prolog)
I can answer:
Interlisp came from BBN (maybe someplace else first),
but Interlisp-D was done at Xerox PARC.

I first used it in 1984, so I suspect it came *after* most of the
key work on Smalltalk.

the window system was written partly in microcode (BitBlt) and
mostly in Lisp. There certainly wasn't any Smalltalk in there;
the Dandelion microstore didn't have enough room for Lisp and
Smalltalk at the same time.

The D machines were lovely machines to use (especially the Dandetiger)
and the window system in Interlisp-D was *amazingly* easy to program.

[Stephane Ducasse]

on 4/26/01 2:45 PM, Henrik Gedenryd at ***@lucs.lu.se wrote:

> Bijan Parsia wrote:
>
>> Now, testing for beginsWith: 'Morphic' gets us:
>>
>> 3379693
>>
>> Bloat at last!!!
>>
>> But gee, to echo your point, Morphic is a *lot* of stuff. There's a PDA, a
>> bunch of games, a EPS outputter, a set of interface widgets (a lot of
>> which are in use in my system, since I'm running in morphic and have a
>> gazillion windows open, etc.).
>
> Right, a lot of stuff, and I've said this before: most of this is not
> Morphic per se, but applications of it. The PDA and the games are typical
> goodies, and so on. Calling these "Morphic" is as logical as if every use of
> MVC would become a part of MVC itself.
>
> And the whole eToy system has nothing to do with Morphic per se. In fact, a
> lot of newcomers are confused (and I sure was) since there is no clear line
> between Morphic and eToy. So when there are really just a few things to
> learn, you have no way of knowing what that is. Etoy is clearly in the
> domain of SqC's own experimentation, and I've said before that it should be
> kept separate. In Stable Squeak I'm pretty sure this will happen. I think
> this alone would cut the number of methods in Morph to less than half of
> what it is now.

And this would be great to have classes that have less than 200 methods ;).
In the same idea, I strongly think that string does not have to know
asURL
as....
asblabla

Because then everything is linked together.


>

[Douglas Brebner]

On Thursday 26 April 2001 04:21, Richard A. O'Keefe wrote:
> Christopher Sawtell wrote:
> >I am not exactly in the flush of youth any more, and for me the pin-head
> > size of the default font is difficult to read.
>
> Bob Arning <***@charm.net> replied:
> I'm curious, do you know about how many pixels per inch your
> monitor generates? Mine is in the low 80's and, although I have
> upgraded my reading glasses several times in the last 4 years, I find
> the Squeak font to be much more legible than, e.g. the TV listings in
> the newspaper.
>
> For what it's worth, on the Solaris box where I usually use Squeak,
> xdpyinfo tells me
> dimensions: 1152x900 pixels (325x254 millimeters)
> resolution: 90x90 dots per inch
>
> If "12 point" type should have a baseline-to-baseline distance of 12
> points, that means 15 pixels (14.944, using "true" points).
>
> One understands that StrikeFonts are bitmap fonts, so they're not going to
> scale easily, but surely 90 dots per inch has been common enough for
> several years to warrant a set of fonts that are the right size for it?
> Can any of the X fonts be adapted?

FWIW I find the default fonts uncomfortable to read on my 100dpi monitor and
my vision is perfect.

[Simon Michael]

Yes, thank you Glyph - an excellent write-up.

Bob Arning <***@charm.net> writes:
> Please bear in mind, too, that Squeak is still an active search for
> a "better" way to do things and this means change.

quite right,

> To expect that all code ever written will continue to function
> flawlessly in all future releases is too much to ask, especially

is a simple dependency mechanism of the kind implemented by eg GNU
smalltalk not practical ?

For what it's worth: on a debian (linux) system, you can install any
package, old or new, and be pretty confident that it will either "just
work", or tell you why it should not be installed.

-Simon

[Stephan B. Wessels]

Aaron J Reichow wrote:

> On Fri, 20 Apr 2001, Stephan B. Wessels wrote:
>
> > Sorry if I appear to be ranting. Does this make any sense or ring true for
> > someone?
>
> I do this quite a bit too. Sometimes it's under the influence of a
> psychedlic (keep war-on-drug comments to yourself, please), but most of
> the time not. Sometimes, I just break out my Juno-60 and find cool sounds
> and sit and makes stuff up for 5 minutes, or an hour.

You just hit on one of the wonderful things that modern electronic keyboards
provide. A friend of mine who is a recording engineer remarked one day that the
Synthesizer is one of the few devices he'd seen where upon hearing a new sound
someone gets an idea for new music.

Another way of looking at this is to conclude that a "creative instrument" makes
ideas (good and bad) natural, free and easy. Is it a stretch to imagine that
Squeak is like this?

Perhaps we all have a varying amount of creative ideas that would benefit from
the proper instrument? Even when it's a tool like Squeak.

- Steve

[Richard A. O'Keefe]

"John R. Hall" <***@lokigames.com> replied to my
observation that the Squeak IDE is actually pretty nice.

-The first few days with Squeak were very difficult. I really didn't know how
to do anything in the environment. I got over that, but it could have been a
more positive experience. This isn't really Squeak's fault; it just happens
that Squeak's interface is considerably different from anything else I've
ever seen.

Documentation, documentation, documentation!

The thing that made getting started with Squeak a breeze for me was
having the coloured books, LaLonde & someone, and the Squeak Reference Card.
The book
Smalltalk-80, the Interactive Programming Environment
was *immensely* valuable. I had our library buy Mark Guzdial's "Squeak ...
Multimedia" book, and it's a very nice little book, but I must say that
I would never have been able to figure the Squeak environment out from it
alone. (Make that a *VERY* nice little book.)

Take the Form editor, for example. Just looking at the icons at the bottom,
it's easy enough to figure out the "tools", but fat left arrow for "load"
and fat right arrow for "save"? *With* the Orange book, a breeze.
*Without* the Orange book, forget it. (I defy anyone to guess the
correspondence between those icons and the bottom two rows of the keyboard
without figure 7.3.) (Why did "file name?" pop up when I selected
Reverse Mode? And why are the icons gone, leaving vacant squares, when I
run the Form editor a second time?)

The Form editor doesn't run under Morphic. What _does_ one use to edit
forms under Morphic?
Take the Supplies flap in a Morphic project. I wanted a bookmorph, but
couldn't tell which little picture was a Bookmorph picture. It finally
dawned on me that I could use the halo on each to find out what it was
called, but balloon help would have been even nicer.

-Squeak's intense reliance on the mouse is likely to be frustrating for
basically anyone but hardcore Macintosh users. I've heard all sorts of
excuses for this, including at least one misapplication of Fitt's Law and
various experimental data to show that mousing is faster than keyboarding.
(It's true that mousing is often faster for new users in _unfamiliar
environments_; keyboarding can become a much faster means of input for
experienced users who know the shortcuts. A bit of keyboard window navigation
would work wonders.)

Documentation, documentation, documentation!

You would be *amazed* just how much you can do from the keyboard.
For example, let's see what it's like to find "OrderedCollection>>addLast:".
First up a 3.0 image.
Cmd-b to get a browser (no mouse or menu).
[move mouse anywhere in top left pane; wouldn't it be great if firing
up a browser warped the mouse there for you?]
Cmd-f OrderedCollection RETURN
[shown "OrderedCollection OrderedCollection OrderedCollectionInspector" menu;
why first two entries identical? Discover that arrow keys DON'T work in this
menu, why not? They scroll the class category pane. That's silly. Select
the first of the duplicate entries with mouse.]
[try TAB to move to next pane. Doesn't work. Why not?
move mouse to top right pane.]
a d d L [typing these keys takes me to addLast:]

What could make this easier for someone who doesn't particularly want to
use the mouse very much?

MENUS
The down arrow key should move the selection down in a menu,
setting it to the first item if there is no selection yet.

The up arrow key should move the selection up in a menu,
setting it to the last item if there is no selection yet.

When there is a selection, the RETURN/ENTER key(s) should select it.

I note that "PopupMenu>>controlActivity" checks for keyboard activity
as well as mouse activity. I note that "PopupMenu>>readKeyboard"
already handles ESC (abort), CR (select), UP, and DOWN, and that
initial letters can be used to move the selection as well.
So why didn't these keys work with the "Class name or fragment?"
menu? Hooray for Cmd-E! Well, that list is made using
(PopupMenu labelArray: "classnames" lines: #(1)) startUp
So these keys SHOULD work in this menu.

Ah! In an MVC project, this DOES work. (I knew there was a reason
why I thought it should.)

I am still struggling with Morphic and couldn't begin to figure out what
would be needed to make the menu keys work in Morphic as well. but are we
agreed that Morphic should not be *less* usable than MVC?

BROWSERS AND INSPECTORS (multipaned things in general)
The obvious key to move to the next pane is TAB. That doesn't work
when some of the panes have editable text, nor do plain or shifted
arrow keys. That leaves

Cmd-Right arrow move to next pane
Cmd-Left arrow move to previous pane

The order typically doesn't matter very much, so sorting things
by vertical position then horizontal position of top left corner
would do. This feature makes a lot of sense in Morphic too.
Consider the Rolodex tutorial we were recently told about. People
would very naturally expect *some* key to move between the text
fields.

-I've heard amazing success stories of Squeak images running continuously for
years at a time, but over the past semester of working with Squeak for a
class I've lost at least 3 hours of work due to random crashes and lockups.
Recovering code from the changes file is a major PITA. To make matters worse,
our class' Swiki crashes on a regular basis, frequently on the night before
projects are due (this has happened at least twice out of six project
deadlines). It's FAR too easy to fry an image. I've managed to do it
accidentally several times.

While poking around to substantiate some of the claims in this message,
I tried (in the initial (Morphic) project) the FormEditor class>>newForm
example. The mouse continued to track, but there was no respone to mouse
clicks, and eventually an error box "Object is not in the collection"
popped up, something to do with trying to handle an exception. Thank
goodness for the File|Quit menu bar item, say I.

This is not a flaw of the *IDE* though, it is just plain flaky code in
the *implementation*. I wonder what Stable Squeak will be like?

-The user interface is... well, clean, I guess... uncluttered,
maybe... not very pretty. I tried to spice it up a bit with various
goodies, but that fried my image pretty quickly.

I don't know what "not very pretty" means. I don't actually *like* the
brightly coloured stuff, because it reduces the contrast on text that is
already at the margins of legibility. I'd have thought that the 3.0
Morphic projects with their Squeak and Supplies and Tools flaps were
"pretty" enough for anybody. I defy anyone to say that Squeak's IDE is
more "uncluttered" or less "pretty" than XEmacs running under Common Desktop
or Metrowerks on a Mac.

-The system is supposedly self-documenting, but much of the system is left
uncommented and without help boxes. This makes it very difficult for
beginners to learn the basic system classes. I've spent many red-eyed nights
untangling the code to try to figure out what's going on, and I usually
succeed, but a few more bits of documentation would help greatly. (Yes, I
know, programmers hate to write documentation, and I'm pretty bad about it
myself, but this small bit of effort would go a long way.)

Documentation, documentation, documentation!

The classic coloured books are amazingly useful. When I loaned my
coloured books to another staff member, I must have asked him "you DO
understand that I'd like these back soon?" at least a dozen times.

Squeak is a bit like Eiffel here. Eiffel has special hooks for documenting
classes so that assorted tools can find things. Do they get used with
anything approaching thoroughness? Not in the Eiffel code (other than
examples from ISE) that I've seen. Java code in Sun's JDK is copiously
commented, with, it must be said, comments that are occasionally wrong and
quite often fail to explain what one needs to know. Even so, it's _there_.

Since access to documentation *is* a feature of the Squeak IDE,
I suppose it *does* count as a defect of the IDE if the documentation
is incomplete or defective.

I rather like books, but I must say that important information seems to be
far easier to find in Squeak than in say Metrowerks. Searching through
multihundred page PDFs is not the most effective way to locate stuff.
And printing them wastes about 50% of the paper.

One thing I'd rather like to see in Squeak is classes linked to tutorials,
as people write them. Certainly the Squeak Reference Card should be part
of the base distribution. The machinery to make and follow such links is
there, it just needs to be used.

-Morphic. This graphical scripting stuff sounds like a neat idea, but I took
one look at such a "script" and found myself asking "WTF??"
The Morphic environment is teeming with cool features, but how the heck is a
newbie supposed to figure them out?

I've been using Squeak for about a year and a half now, and I am still
pathetically grateful for Morphic tutorials. (This is despite having a
copy of Self and having read the Self Morphic paper.)

Documentation, documentation, documentation!

(I have done my share of documentation on a commercial software project.
I'd say it's at least as much work as writing the code, but BOY does it
make a difference to the quality of the product.)

[Bob Arning]

I followed the links from slashdot back to GaTech and one would find it easy to conclude that the source of these comments is an unhappy camper in general.

Cheers,
Bob

On Wed, 18 Apr 2001 08:55:51 -0700 Ned Konz <***@bike-nomad.com> wrote:
>On Wednesday 18 April 2001 07:21, Wouter Gazendam wrote:
>> Might be an interesting advocacy:
>> http://slashdot.org/article.pl?sid=01/04/18/001236&mode=thread
>>
>> Wouter
>
>There's an interesting response from a Georgia Tech student (one of Mark
>G's?):
>
>http://slashdot.org/comments.pl?sid=01/04/18/001236&threshold=1&commentsort=0&mode=thread&pid=52#60
>
>The overall tone is summed up by:
>
>"Squeak has been the worst programming language I've ever had to deal with
>(out of the seven or eight I've learned).
>The Squeak IDE is one of the most frustrating pieces of software I've ever
>had to use."
>
>But (s)he goes on to describe why.

[Bob Arning]

Glyph,

First, let me say thanks for someone who can put their gripes in perspective and avoid unnecessary hyperbole. Here are some thoughts:

On Thu, 19 Apr 2001 04:32:11 -0500 Glyph Lefkowitz <***@twistedmatrix.com> wrote:
>There is no clear way to write an application in smalltalk. From the minute I understood what an "image" file was, I realized that this could be an interesting issue, but the real deep problem is that the community (or at least Squeak Central) doesn't seem to take this seriously, since it's certainly possible to create custom image files that do what you want your application to do. It seems like the attitude is that writing software that will last for more than a few months involves maintaining a fork of some version of the baseline virtual machine yourself.
>
>In search of someone else's answer to this problem, I scoured the net for changesets, loading everything that I could. I downloaded approximately 50 changesets, and every single one either gave me a walkback upon filein or conflicted with another seemingly innocuous changeset in such a way that a basic task (opening a Browser window, or better yet, entering the debugger) would give me a walkback.
>
>Despite the pleasantness of the debugger, the sea of broken links, broken instructions, and broken code only gave me three conclusions to jump to:
>
>1. The open-source segment of the squeak and smalltalk community in general is a bunch of slobs who just write broken code and expect their users to deal with it and/or fix it.
>2. Nobody actually uses squeak for anything but writing the squeak VM, and it is in fact unusable for anything else.
>3. It is nigh impossible to actually write and maintain a significant amount of code which stays current with the SqC image, despite many heroic efforts to the contrary; so you have to have 6 or 7 different images lying around that you can actually run squeak code.
>Various things about my investigations into the squeak community show me that conclusion number 3 is probably the true one, but I could easily see a frustrated, but slightly less curious person than I in the same situation jump to 1 or 2, and go back to their previous language of choice. It is my sincere hope that the Stable Squeak project will fix this, and make most of this little rant invalid in 2 months time. :)

WRT the 50 change sets you found on the web, it may be that the authors (and I could be one of them) never bothered to update their code for newer versions of Squeak. Sometimes the lack of response from the user community or loss of interest by the author consigned them to the "no longer supported" category. If folks do care about the change, I suspect it will likely be kept updated or even brought into the main image. Please bear in mind, too, that Squeak is still an active search for a "better" way to do things and this means change. To expect that all code ever written will continue to function flawlessly in all future releases is too much to ask, especially when some of the things you may have downloaded were clever modifications to the base image that the author felt provided sufficient benefit for the risk involved.

WRT maintaining your application in the face of this change, there are several options:
1. Stick with one base image. Choose a Squeak version - 2.8, 2.9, 3.0, whatever strikes your fancy, and don't update it. Your application will basically run forever, assuming you can keep the underlying OS and hardware functional for that long. ;-)
2. Pick an image and stick with it until the next release is final. Use 3.0, e.g. up until the time 3.1 is finished. Then (and perhaps waiting a bit longer to let someone else find the *last* bug) migrate to the new version. If you have written defensively, this probably won't be a big deal. I've migrated my email client from 2.4 to 2.5 to 2.8 and it's never been a big job - and I'm totally flagrant in my disregard for boundaries.
3. Grab the latest alpha release and take every update as it comes. You'll find that you have more frequent pauses to re-sync your code than in the previous approach, but they will likely be shorter pauses and they will be occurring at the same time others on the list are going through the same issues so there is likely to be opportunities for sharing tips.

I think any of these can work. Which suits you depends on your own style and the needs of the application.

>* too configurable: Why isn't inboardScrollBars default? Is the 6 pixels of saved screen real estate really worth confusing everyone who's never used a smalltalk system before?

Do you really mean *six* pixels? After complaining of carpal-tunnel-inducing features, did you actually turn ON narrow scrollbars? :-) If you take the standard 16 pixels and multiply that by 4 or 5 for some browsers, remember that some folks may have smaller screens than yours, think about wanting to see two browsers side-by-side, etc, it's not too hard to see why having flopout scrollbars would appeal to some. Add to that the implicit indication of focus they provide and I often find myself wondering why so many OS's and applications have scrollbars permanently visible.

>Why would you ever turn smartUpdating, decorateBrowserButtons, or optionalButtons off?

I have smartUpdating on, but occasionally wish I didn't. I have in the past kept two different versions of the same method in two different browsers as a quick way of toggling some code when I was trying to see which worked best under different circumstances. That said, I agree, it's a good thing. As to the buttons in the browser, they are off in my image and will stay off. My primary goal is to see the code and understand it - anything that might lead my eye and brain elsewhere is suspect.

>Also, I've twice accidentally removed a button from a window without any clear way to put it back... it seems like there ought to be some modality associated with editing/exploring the GUI vs. using it.

I was about to say that there is... Oops, there *was* a way, but it appears to have been disabled, itself. I'm not sure whether this was intentional or a side-effect, but it's easy enough to reinstate should one so choose. Let's think, though, about what it means. One of the things that makes Squeak so interesting is the direct manipulation of things on the screen and that means basically everything on the screen. Disabling this entirely is easy (as would be re-enabling it), but I suspect that, having done that, the next call would be for disabling the editing/exploration of *some* morphs but not others (after all, what is the GUI and what is other stuff?). Endless debate could ensue on this point.

>If you resize a window or pane, the resizing rect will flicker violently until you move the mouse.

That's interesting - some Unix users reported this a few months ago, but I was never able to duplicate it on my Mac. It appeared to be a difference in the way the respective VM's reported events. Just for fun, I repeated the experiment today and did see it. Looks like the Mac VM has finally caught up(!?) with the Unix VM in this regard. I'll see about getting that fixed soon. FWIW, this only appears when the preference #fastDragWindowForMorphic is on. I run with this one off - have you tried that?

>* lacking in features: There is no such thing as an "open" dialog, or a menubar, or a tabular data display widget, as far as I can tell. (of course, this could just be an artifact of the next point) The "file list" window is almost a reduction to absurdity about bad UI. The C community has Nautilus, and Smalltalk has managed to come up with this?

Could you say a bit more about what you find lacking? I don't know whether it addresses any of your complaints, but there are some alternatives - see the class comment in FileList2, e.g.

Cheers,
Bob

[Andrew C. Greenberg]

Despite the righteous indignation manifest here at my apparent lack of
civility, I'll stand by my remarks. (I'll also stand on my netrep for
civility). To the extent that I appear upset, you may take it that I am.

Forking an open source project is not a civil thing. It is almost
unanimously held by most of the leaders in open source movements
(Perens, Stallman and Raymond) that a fork, an inherently divisive
activity, requires a compelling reason. The ordinary course of conduct
in an open source project is to "just do it." Make a contribution and
share it with the community. The present, "I'm going leave and take
your ball with me" attitude I have seen is repugnant to me, but that I
have discussed on the merits, in this forum. Again and again.

A corollary of this proposition is that agitating for a fork (rather
than simply doing it), without substantial consensus, is uncivil. In
most projects, wannabe forkers are treated accordingly, reminded of the
nettiquette of what they are doing, occasionally reminded of the "just
do it" open source ethics and ultimately asked to cease and desist.
This being a far more rarified community, that isn't necessary. But
this particular dispute

Why I am upset at Paul's remarks is that they pushed a button that
should never be raised, suggesting that the fork was necessitated by
some acts or forebearance of Alan Kay and his extraordinary research
group at Disney R&D. This is this last straw. Not the continual
threats about forks (I will spare the flame-baiting by quoting the
archives -- this is apparent to anyone who has lived here for any length
of time). Not the Squeak-baiting, some justified, some not. Some
petty, some worthy.

Why I am upset is the suggestion that there is ANY ONUS AT ALL upon
Squeak Central to do anything. It is, in fact, the most ungrateful and
obnoxious conduct I have ever seen in the open source community. It is
outrageous, regardless of the merits of any claim to a need for a fork
(which I have previously argued on the merits to be ludicrous). Here's
why:

1) These guys have performed magic, providing an outstanding, fast and
portable Squeak system, and the basis by which this community has arisen
from virtually the ashes of a dead system -- original Smalltalk-80.
These world-class geniuses and technical wizards deserve nothing less
than our unqualified respect and, at least, reasonable courtesies. [I
do not suggest that this forum devolve into a supplicating crew of
accepting "yes-men." I can think of nothing that would insult our
in-Disney colleagues more than withholding our best thoughts and
efforts.]

2) These guys owe us nothing. This was unselfish, free and wonderful --
they have fought fiercely the politics of both Disney and Apple to make
Squeak available on the terms on which we are getting them. They have
supported the community at length, in many times when the projects were
cross-purpose (or at least did not directly support) with their
research. They do good. We should be greatful. [This is not to say
they shouldn't likewise be greatful for the contributions of the
community, which has developed and fostered well their works to date.]

3) For these reasons, the statement that the "only way to stop the fork
is for SqueakC to make modularity a top priority ASAP (ideally built
from textual source)" is nothing less than petulant. It is uncalled
for. It is uncivil. If a fork happens, it is because those who have
forked couldn't figure out how to work with the community, or because
those who are agitating for the fork can't even do that. It will not be
because of anything that Squeak Central has done or not done.

Look guys, this is open source. Just do it. Fork if you must, but if
you abandon this community, could you take it outside? Or at least
spare us the righteous indignation when people grow upset at the fact
that an unnecessary fork of an open source project is occurring at your
hands.

Aside from being wholly uncivil, I would further raise another practical
problem: this is also precisely the sort of thing that makes companies
like Disney reconsider their involvement in open source projects.

On Saturday, April 21, 2001, at 03:31 PM, Les Tyrrell wrote:

>
> ----- Original Message -----
> From: Paul Fernhout <***@kurtz-fernhout.com>
> To: <***@cs.uiuc.edu>
> Sent: Saturday, April 21, 2001 9:22 AM
> Subject: Re: Smalltalk & Squeak featured on Slashdot
>
>
>> "Andrew C. Greenberg" wrote:
>>>> The only way to stop the fork is for SqueakC to make modularity
>>>> a top priority ASAP (ideally built from textual source).
>>> Nobody can stop someone who wants to write a fork.
>>> Clearly noone can stop Paul from threatening one.
>>
>> Andrew-
>>
>> I'd appreciate a more precise use of language when you imply for
>> example
>> that I am "positing threats" about a fork.

Paul insisted that a fork is already being undertaken, and that unless
Squeak Central gets its act together, it cannot be stopped. His precise
words are quoted above, and should be understood in its full context.
Further quotes and details simply invite me to participate in a personal
flamefest to which I will not be a party. Suffice it to say that I'll
stand on my remarks.

> I'll second that notion. The thing I find particularly disgusting
> about this whole thing is that I
> actually have known Paul in the past, and found him to be a very
> polite, kind, soft-spoken, and
> considerate person. The way you continually depict him as being either
> threatening or disruptive to
> this community is something that I find appalling. I especially find
> it appalling that anyone who
> brings up the topic of Modularity in Squeak can expect the same sort of
> treatment from you. Some of
> us have been looking at this problem for a long time, and have worked
> mighty hard on our own time
> and without compensation of any kind to find a solution that makes
> sense for Squeak. Kindly
> consider that in the future.

This remark reminds me of discussions of tax cuts. Ok, your taxes are
too high. Well, sir, so are mine.

I think we have all put spit and blood into Squeak. Most of us managed
to find a way to work within and among the community. Most of us have
shared our works, as works in progress and in final form. We have found
ways to make a single, unitary whole out of the community's work. You
may calm yourself in your concerns that you find my criticism
"appalling" as an attack on "anyone who brings up the topic of
Modularity in Squeak." Nonsense. I myself have made comments and
contributions to that end. I don't even disagree with some of the
specific suggestions and remedies that have been proposed. I think a
fork, and the calls for one, however, have been empty on the merits. I
also have seen the comments in defense of them to be silly.

But I don't call for a fork, and I will hold anyone who agitates for a
fork to the same standard that Perens, Stallman and Raymond would hold
them. Count on that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 7119 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010421/84f13855/attachment.bin

[danielv at netvision.net.il ()]

Please don't read something in my post that isn't there.
I don't find modularity a sexy topic, but I've been bitten by the consequeneces. If Oasis or some other contribution were to improve the longevity of peoples contributions, I'd be glad too.

BTW, there are other means to that intention - tools or ways of working that make the work of (re)integration easier are another path (RB, adding SUnit suites to contributions). I think cross-dialect frameworks (an anti-fork?) that really work (SUnit is an example) are yet another.

So - new ideas, demos and implementations - cool.

But forks - I don't think forks are an effective means to our various, mostly shared goals. They only add limits to the scope for each contribution. As a subject they relate more to the political than to the technical, and thus aren't what *I* hope to get from this forum.

So - Forks not cool.

And please nobody tar Bijan, I still hope to clear a debt of useless advice ;-)

"Les Tyrrell" <***@canis.uiuc.edu> wrote:
> Daniel,
>
> Sorry if this topic has become acrimonious. That certainly wasn't the intent of those of us who
> actually care about this topic, and have spent considerable effort on the issues behind it. I for
> one would love to have a lively, ongoing discussion on this list about the issues that are going to
> have to be addressed in order to bring modularity to Squeak. There are many of them, and I think
> that most people on this list would find that discussion to be very interesting, and very relevant
> to them.
>
> - les
>
> ----- Original Message -----
> From: <***@netvision.net.il>
> To: <***@cs.uiuc.edu>
> Sent: Saturday, April 21, 2001 4:32 AM
> Subject: Re: Smalltalk & Squeak featured on Slashdot
>
>
> > I wonder - can anyone please create a squeak-fork mailing list?
> > it would be devoted exclusively (and be the only appropriate place
> > for) to disscussion of squeak forks that are not happening.
> >
> > Discussion of actual Stable Squeak projects and achievements
> > would still be appropriate to this list, IMHO.

[Jerry Jackson]

> -----Original Message-----
> From: Alan Kay [mailto:***@disney.com]
> Sent: Thursday, April 19, 2001 9:34 AM
> To: ***@cs.uiuc.edu
> Subject: RE: Smalltalk & Squeak featured on Slashdot
>
> >
> Guess where the Interlisp-D environment came from ..... and when ...
> and what code was used to do its window system .....
>

I guess I should have known :-) I knew that a lot of Smalltalk work was
going
on at Xerox but I was pretty immersed in the Lisp world and didn't really
dig into it.
I even attended a LOOPS workshop at PARC once but the Xerox folks involved
(mainly Dan Bobrow and Mark Stefik) never really made a point of the debt
that the LOOPS system owed to Smalltalk.

It's really pretty sad that back in
the mid-80's I was surrounded by amazing programming environments (in the
AI lab at NOSC in San Diego) -- Interlisp-D machines, Symbolics and LMI
machines, etc.
When they didn't catch on in the mainstream I assumed it was because they
all ran on
expensive, unusual hardware. Later when Harlequin came out with a decent
CommonLisp
environment that ran on commodity hardware I thought things would change (so
much so that
I went to work at Harlequin for a while :-).

Here we are close to 20 years later and IDEs are everywhere but they're
almost
universally lame. I have yet to find an IDE for any of the 'C' based
languages (including
Java which I spend most of my time doing) that can wean me away from Emacs!

Thanks for the history lesson, Alan!

[Peter Crowther]

> From: Stephan B. Wessels [mailto:***@sdrc.com]
> Perhaps we all have a varying amount of creative ideas that
> would benefit from
> the proper instrument? Even when it's a tool like Squeak.

*Especially* when it's a tool --- or, more generally, toolbox --- like
Squeak. Creative flow tends to stop abruptly when the tools to express that
flow aren't readily to hand or cannot be found, whether that's painting,
sculpture, music or programming.

One of the great advantages of Smalltalk in general, and Squeak in
particular, is that the tools are likely to be in the toolbox *somewhere*.
One of the great *dis*advantages is rummaging around that huge toolbox
trying to find the tool you want, and knowing that someone's likely to have
built it in a form much more elegant than the one you just had to build but
didn't want to spend any time on. Nobody's entirely solved that particular
problem, although the code-fragment-locating tools in Squeak come the
closest of any I know.

- Peter

[Bijan Parsia]

On Sun, 22 Apr 2001, Glyph Lefkowitz wrote:
[snip]
> The issue of modularity, which I believe will keep an upper limit on the size
> of the Squeak community at approximately its current size (an assumption
> borne out by a lengthy perusal of the mailing list archives and a google
> search for 'squeak smalltalk', which shows developers frequently drifting to
> squeak briefly and then away from it, or refusing to maintain their software
> and/or update it for a recent SqC `blessed' image, for these reasons),
[snip]

Well, "bourne out" is strong, since I look at the same evidence and see
steady Squeak Community growth. Continual.

Now *of course* people drift in and away...that's, imho, the nature of the
world. And *yes*, of course, there have been nifty things which fell (at
least for a while) by the wayside. OTOH, I can point to huge chunks of
useful functionality that used to be separately loaded goodies (everything
from PWS, to the ObjectExplorer, to SUnit). Yes there have been some
frictive moments and some noticiable "failures" (e.g., I wish we'd had
block closures a year and a half ago, sockets are still touchy). I know
that made some people, for example, use WikiWorks over Swikis. Er..but
WikiWorks is a *good* thing. :)

Would Modularity make all this better....maybe. Would it make it better
"enough"...maybe. Getting events was nice, but I don't see the
reverberations have quite died down from that ;)

Finally, and this is an old saw of mine, quick growth or even large growth
isn't necessarily a happy thing. I'm *not* of the world domination
mindset. I'm happy there's things like Ruby. Or VisualWorks, or Dolphin.

Note that much of getting things into the base image is a matter of
volunteer work (and kudos to Stefan Matthias Aust for all his work (hmm,
someone else was doing this too, yes? Kudos to you!:))).

Cheers,
Bijan Parsia.

[Andrew C. Greenberg]

On Friday, April 20, 2001, at 12:52 AM, Tom wrote:

> On Thu, Apr 19, 2001 at 09:42:07AM -0400, Bijan Parsia wrote:
>> Anyhoo, none of our flapping gums is going to do much, since all these
>> lines are well known. Code is prolly more convincing.

> I think that's a separate question. My personal opinion is that an
> advanced IDE should have automatic window management and it should
> have a
> very rich set of key bindings. But other's preferences may differ;
> not all people are alike.

Reasonable people may disagree on this point. I don't see this as
hugely important, but hey, that's what open source is about. If a "very
rich set of bindings" would be important to you as a user, prove it up.
As Bijan put it, none of our flapping gums means anything -- code is
convincing.

> But to attract new users, I think the main issues are the ability to
> customize the system to reduce cognitive load, the ability to solve
> real-world problems easily out of the box, and quick, unobtrusive
> obvious
> paths for access to relevant help and documentation. Emacs hardly
> shines
> in these areas. Squeak actually has a much better chance, since most
> of the bits and pieces already exist (key bindings, customizable LAF,
> OS interfaces, GUI widgets, help system); with Squeak, it's less about
> programming and more about packaging.

I don't get this. Why is Squeak "more about packaging?" To me, Squeak
is more about the amazing power it has under the hood.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1576 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010420/769109c7/attachment.bin

[danielv at netvision.net.il ()]

I wonder - can anyone please create a squeak-fork mailing list?
it would be devoted exclusively (and be the only appropriate place
for) to disscussion of squeak forks that are not happening.

Discussion of actual Stable Squeak projects and achievements
would still be appropriate to this list, IMHO.

I think that would be a worthwhile fork ...

Daniel
"Andrew C. Greenberg" <***@mucow.com> wrote:
>
> On Friday, April 20, 2001, at 09:43 AM, Paul Fernhout wrote:
>
> > "Andrew C. Greenberg" wrote:
> >
> > The issues of why it had to happen have been outlined in numerous emails
> > on this list.
>
> And their validity was likewise addressed. By referring to "reasons
> previously stated," I refuse to re-engage in an already ridiculously
> overhashed issue.

> Nobody can stop someone who wants to write a fork. Clearly noone can
> stop Paul from threatening one.
>
> The only issue is whether the exercise is detrimental to Squeak and its
> community. The gurus of open source have uniformly posited that there
> should be a compelling reason for one. Perhaps reasonable people might
> differ on this point, but I still believe that it is ludicrous to
> suggest that any major departure from the existing model is necessary.
> Modularity projects may be proposed, implemented and distributed in
> Squeak through the "ordinary course."

[Jarvis, Robert P. (Contingent)]

> From: John R. Hall [mailto:***@lokigames.com]
>
> <thoughtful comments on Squeak snipped>
>
> So, yes, I can understand why a student might proclaim
> frustration with Squeak.

Yes, I can understand your points. I'll offer the following counters:

1. Yes, Squeak (and all Smalltalks) are different. In the words of the old
Burger King commercial, "different is good". In the past <mumble> years of
programming computers I have yet to find anything I prefer. To paraphrase
Churchill's comment on democracy, "Smalltalk is terrible. It's inefficient,
slow, bloated, and a damn pain in the ass to figure things out in. It's
*only* saving grace is that it's better than any other way humanity has yet
discovered for programming computers". All IMHO.

2. I agree, mice are not the be-all and end-all of input/manipulation
devices. Good keyboard shortcuts (above and beyond what's already there)
would be a Nnice Thing.

3. Instability is bad. Let's hope Stable Squeak/Pink Squeak/Business
Squeak/BizSqueak (my personal favorite :-) will be able to help here.

4. I like the clean look of Squeak. YMMV.

5. I can understand your point, having spent my time digging through
classes to try to figure out what's going on. On the other hand, at least
you've got the classes to dig through. Compare this to working in something
like VB where you're trying to use a control produced by a third party; said
control doesn't work as per documentation, the company who made it is
defunct, the source code for the control is not available, the guy who wrote
the program you're working on quit two years ago, you've got to get things
working, your boss wants the program changed/fixed yesterday, layoffs have
been announced and your department figures prominently in the "opportunities
for cost reductions" column, AND your doctor says you should do something to
reduce your stress levels. See - Squeak isn't so bad... :-)

Bob Jarvis
Compuware @ Timken

[Richard A. O'Keefe]

A couple of people have now answered by "who is harmed by the present image
size" questions.

Looking back through an old OOPSLA proceedings, I stumbled across a
paper about Squeak. The image back then was about 1MB. Now it is about 9MB.

It would be interesting to know roughly where the space is going.
- IDE
- Morphic
- Scamper
- Celeste
- Balloon3D
- Alice
- Sound
- Speech
- ...

Scamper is cute, but it feels even slower than HotJava (which is saying
something) and I can't print from it, so *for me* it is bloat.
Celeste is cool, but I continue to use /usr/bin/mailx as my mailer
precisely because it *can't* do fancy things, and I had trouble hooking
it into UNIX mail anyway, so *for me* it is bloat.
3D graphics is an important part of making Squeak a great multimedia
system, but *for me* it's bloat.

I put up with this "bloat" for several reasons.

One hasn't been mentioned in _this_ context, at least not recently.

If something isn't in the base image, it stops working.
Simply because all of these "modules" share an address space,
you have no reason to believe that a "module" will work in any
combination of modules you haven't actually tested it in.

The things I've mentioned as bloat *for me* are core functionality for
many many other people, and it is important that those things not stop
working.

There is an indirect benefit, or would be if I knew how to run regression
tests for all those other things. If I develop something useful (and I'm
working on it, I'm working on it) I would like to be sure that it won't
break anything.

Now, I don't delete any existing classes, and I don't delete any existing
methods, but I *do* add some methods to existing classes. (For example,
I have added methods
reverseDetect: aBlock ifNone: exceptionBlock
reverseDetect: aBlock
to SequenceableCollection.) That could well break some other project
that wants to use these methods for something else. (In the case of those
two methods, I seriously doubt it. But you never know. And they are not
the only such methods.)

It would certainly be nice to be able to do "Smalltalk testEverything" before
going home at night... There's something I don't know, isn't there (:-)?

Anyone who would like to use Squeak, but does a lot of programming "for the
web" (e.g. needing to run on someone else's webhost where they only have CGI
access) or system administration. It seems like novice programmers
(sysadmins with little programming experience) would be greatly benefitted by
squeak's environment, but would be unable to squeeze the image down into
their environments where something like Python, Perl, or sh would be
suitable. (The python and perl environments end up being about the same size
as squeak, and take much longer to load if you need everything -- but you
have options as to how much you want to load.)

An empty wish or TkPerl isn't that far off Squeak 1.x in size. (AMAZING!)
(We're talking orders-of-magnitude here, not percentage points.)

> It seems fair to say that if you are happy to use Acrobat reader, the size
> of Squeak 2.7 should not worry you either.

If you're thinking in terms of huge graphical applications, yes.

It is not at all obvious to me why Acrobat Reader *should* be a "huge"
graphical application.

But if you're talking about scripts or CGIs, it's a problem.

Is _any_ Smalltalk dialect used for such applications? I suppose
GNU Smalltalk or Budd's Little Smalltalk might be usable.

Squeak is
- a multimedia library
- a compiler and development environment
amongst other things. Let's compare it with another OO compiler.

I ran javac, compiling a 60-SLOC example from IBM. (ClientServer.java, if
you know it.) Total VM size: 38MB; RSS: 15MB. And that's just compiling.
Somehow, I don't think Sun's "javac" does 3D graphics in its spare time...

I found this result for java very very surprising. Don't take it too
seriously until someone else can reproduce it. The command I used was

javac ClientServer.java & ps -lu -u $LOGNAME

I'm not sure that I *have* a position on the "is Squeak bloated" question.
I can see value in having a smaller image; but everywhere I look I see
systems that are _less_ useful to me taking _more_ memory.

[Andrew C. Greenberg]

> Ummm... you misunderstood; what I was suggesting was: "making Squeak
> more
> beginner-friendly is more about packaging existing pieces, rather than
> programming a lot of new functionality, because the pieces themselves
> already exist and do not need to be written from scratch (unlike, say,
> if you had to do the same for Java)".

I thought so, too. Then I started working my kids through Squeak. They
got it at once, and in ways I never expected. It was a hoot to watch.

Anyhow, nobody is suggesting that changes are bad -- indeed, far to the
contrary. But packaging is not the fundamental priority or what Squeak
is all about. It is, of course, another thing the community can (and
should) be working on. By all means, please join us and do the nasty!

For my part, I join those who feel that far more time needs to be spent
on documentation efforts, ideally with an eye towards highly
maintainable documentation.

[Adam Bridge]

on 4/18/01 6:10 PM, Paul Fernhout at ***@kurtz-fernhout.com
thoughtfully wrote:

> (replying to other comments in this thread) Personally, I still like
> reading Slashdot. It may have a problem with signal-to-noise sometimes,
> but you can always browse at +2 or higher to eliminate much of the
> clutter. Considering how Slashdot readers might come look at this list,
> we might want to be a bit more broadminded.

One of the great pleasures in Squeak-dom is the civility of discourse which
seems a fundamental here.

I think Paul's response to the concerns expressed on Slash-dot is a perfect
example of this sense of collegiality which leads to exploration and
creativity: that is he took what could be a divisive and insulting set of
remarks and allowed (well, me) to see something deeper in them.

Thank you to all who participate here -- keeping the ideas where our heads
ought to be.

Adam Bridge

[Bijan Parsia]

On Thu, 26 Apr 2001, Richard A. O'Keefe wrote:
[snip]
> Looking back through an old OOPSLA proceedings, I stumbled across a
> paper about Squeak. The image back then was about 1MB. Now it is about 9MB.

A shrinked image (with MVC and IDE) can prolly still come in under
1MB. With Morphic and a few other yummies you should be able to stay under
2.5 or so.

> It would be interesting to know roughly where the space is going.
> - IDE
> - Morphic
> - Scamper
> - Celeste
> - Balloon3D
> - Alice
> - Sound
> - Speech
> - ...
>
> Scamper is cute, but it feels even slower than HotJava (which is saying
> something) and I can't print from it, so *for me* it is bloat.

Hmm. I'm surprised at that. Scamper (for many things) is pretty nippy for
me. Two things which seem to get boggy are 1) downloading (and when this
gets bad, it's all bad ;)) and 2) scrolling really large pages (a know
problem with text morphs).

> Celeste is cool, but I continue to use /usr/bin/mailx as my mailer
> precisely because it *can't* do fancy things, and I had trouble hooking
> it into UNIX mail anyway, so *for me* it is bloat.

Well, it's "not used" :) Part of the problem with this is there are
"parts" of Celeste and Scamper, such as the URL classes or MailMessage,
that are things one most likely would like to have around. I.e., once you
get past the bits of these things that are really extentions of the core
system, what's left isn't (always) that huge.

But, of course, if you don't need them, you don't need them.
[snip]

But here's a tip to help figure some of this out. SystemDictionary has a
few useful space analysis tools in the miscellaneous protocol,
especially #spaceTally. From it's comment:

"Answer a collection of tuples representing the memory space (in
bytes) consumed by the code and instances of each class in the system. The
tuples have the form:
<class> <code size> <instance count> <space for instances>
-----
(If you run this, be prepared for it to take a little while ;)

I ran this little do it on the result:

self detect:[:i | i first name = #Scamper]

and it gave me:

#(Scamper 9631 0 0)

Which, of course, doesn't cover much of the scamper classes. So I ran
this:

| categories |
categories := #(#'Network-Url' #'Network-Web Browser'
#'Network-HTML Formatter' #'Network-HTML Forms'
#'Network-HTML Parser Entities'
#'Network-HTML Parser' #'Network-HTML Tokenizer').
categories := self select: [:i | categories includes: i first category].
categories inject: 0 into: [:total :i | total + i second + i fourth]

And got:
71026

Changing the assignment:
categories := #(#'Network-Mail Reader').
yields:
55085

These are *not* the big sources of image growth :)

A slight modification:

| categories |
categories := self select: [:i | i first category
beginsWith: 'Balloon3D'].
categories inject: 0 into: [:total :i | total + i second + i fourth]

Yields:
435885

Now, testing for beginsWith: 'Morphic' gets us:

3379693

Bloat at last!!!

But gee, to echo your point, Morphic is a *lot* of stuff. There's a PDA, a
bunch of games, a EPS outputter, a set of interface widgets (a lot of
which are in use in my system, since I'm running in morphic and have a
gazillion windows open, etc.).

Not to shabby for an experimental, unoptimized system.

(This is out of 13.6 MB image, which, obviously, has seen some use and has
a fair number of extras loaded.)

(Assuming I haven't blown the calcuation any :))

This is *not* to say that I won't be happy when Squeak gets a Smalltalk/X
like "load on demand" facility. Indeed, I'll be all the happier!

(FWIW, classes are generally cheap in Smalltalk. Just having more classes
isn't going to swell your system a lot. Ok ok, CompiledMethod leads the
space filling with an instances space size of 2228576, but that's with
*36496* instances!)

> Is _any_ Smalltalk dialect used for such
applications [i.e., shell scripts and cgis--ed]? I suppose
> GNU Smalltalk or Budd's Little Smalltalk might be usable.

SmallScript is certainly targeted to those applications (among
others). Quick start up and dynamic loading are big features (it doesn't
store an image, but always reconstitutes one from files).

> Squeak is
> - a multimedia library
> - a compiler and development environment
> amongst other things.
[snip]

And, really, at it's heart, a place to inhabit.

(And *no* you don't want to see my house :))

> I'm not sure that I *have* a position on the "is Squeak bloated" question.
> I can see value in having a smaller image; but everywhere I look I see
> systems that are _less_ useful to me taking _more_ memory.

Indeed! And worse, less *interesting*. All I can *ever* do with Acrobat is
crash my machine^H^H^H^H^H^H^H^H^H view and sometimes print a subset of
pdfs I encounter. I, personally, get some entertainment from browsing
around the system and playing around with morph toys.

However, I've advocated that just as we have a "tiny" image around, it
wouldn't hurt to have a few "midsized" images around. Perhaps as a first
step toward discovering some natural "break lines" in the system.

Cheers,
Bijan Parsia.

[Stephane Ducasse]

If you are interested in having the possibility to have different key
shortcut with instance based paragraph or textmorph. I have a changeset that
introduces that in 2.8 and work well.
Just ask

>
> I just released MagicKeys, a graphical utility for doing just that: viewing
> and adjusting keybindings (and importing/exporting them). It even comes with
> some e-macs like keybindings. Check out the webpage at
> http://www.iam.unibe.ch/~wuyts/magickeys/ for more information and some
> screenshots to see what I mean. It is for VisualWorks, but could of course
> be ported to Squeak.
>
> The implementation consists of two parts:
> (1) reading an instance of DispatchTable, and converting it to something
> that makes sense and is readable (and converting that back to a dispatch
> table). This was the hard work: reverse engineering the dispatch table,
> paragraph editor and FeelPolicy.
> (2) the GUI to capture keystrokes, define keybindings, sort them, etc.
>
> I can have a look to port (1) in Squeak (which is necessary to port the
> GUI), but I don't have the time to create the -for the user- all important
> GUI part.... Anybody up to the challenge ? Maybe we can do this at the
> Stable Squeak event at ESUG in Essen ?
>
>
>
> --
> Roel Wuyts Software Composition Group
> ***@iam.unibe.ch University of Bern, Switzerland
> Board member of the European Smalltalk User Group: www.esug.org
>