At 03:09 PM 3/30/2002 -0500, Bijan Parsia wrote:
>Learning how to explore Squeak from the app into the code is a key
>"aha" moment, in my experience. Obviously, you haven't gotten there
>yet. It might be interesting to know what books/articles/whatever you used
>so we can rectify them a bit.

Didn't use any.  Just picked it up, and started poking at it.
Couldn't quite figure out where the source code was.  I thought
the flapping windows were a little weird -- if nothing else, it gives
the idea that you can't really tell what you might or might not
be able to do, until you actually poke it with the mouse.  This
meant, when looking for source code, that I was never really sure
if I had looked properly (I am working from recollection here,
it was some months ago).  Eventually, I have better things to do.

I will try again.  (Much time passes.)

Okay -- there is a bit of a theme to all the problems,
and that is that the system is too tuned to expert use.
Just for example, the tool tips take .8 second to appear.
Why should a beginner be forced to wait to see these?
So, I have a quest, which is to find that delay, and reduce it.

There's insufficient cues.  Over in the tools thing (that pulls out
of the right border) there's no clear cue that what you are supposed
to do is click AND DRAG.  I ended up with some large number of
funny yellow dots over there in the flaps, they must mean something,
I can't make them do anything. 

And the world menu, why does it need a special "dismiss this menu"
selection, instead of a little X in the upper left corner to make
it go away?  What's going on here?  Why this inconsistency?
There must be a reason, but it seems really ridiculous to have
"dismiss this menu" spelled out as a choice.  (And no, I don't
think it would improve things much if you explained it to me.
It would seem just as ridiculous to the next person who had not
heard the explanation.)

It's difficult to "find" things.  I eventually decided that what
I needed to do was find some message senders (for some message
related to balloons, can't recall what).  Is it "find"?  Nope.
Eventually, on a lark, I happened to right-click over in the
unlabelled list that *happens to contain* what appear to be
message names, and I discover the "senders of ..." choice.
Now, I suppose, if I were playing Adventure, I would say
"aha", but otherwise I'm just turning over rocks looking for
pretty minimal treasure.

So, after much looking, I find the method that contains the
time for delay before display the help balloons, and change
it to 100 ms.  Now I'm ready to save my change.

(Digression:  A much less diplomatic rant was deleted,
and I decided to substitute something more useful and perhaps
productive.  So, here I am, trying to replay my actions, and
I CANNOT FIND the code that I found once already.  That's not
good.)

So, I'm ready to save my change.  That's save, spelled, apparently,
a-c-c-e-p-t.  At least, I hope that was right -- it asked me for
my initials, and I wonder, in hindsight, if there was some sort of
a try-it-out-before-committing button that I should have
hit first (I mean, who knows, maybe I failed to turn over the
UI rocks in the proper order?)

This all seems a little terse, and it seems like a gratuitous
change of jargon.  Why not call all the finding things "find", 
and all the saving things "save"?  Why not label the columns of
stuff so I can know for sure what they contain?

But now, with my faster help tips, I went poking through
the music player, and selected something ("ratio") under
the something menu on the waveform (light green) window,
got a zero divide (why?) dismissed the exception notice,
and now the waveform window is blank and useless.  I wish I
knew how to reset/restart it.  Oh Well.  Maybe the exception
window went somewhere, and I should go looking for it.  Nope,
can't seem to find it.

The learning curve here is really unpleasant.  I can compare
this with a couple of different things I've picked up in recent
months.  One was DrScheme, from Rice.  I already knew Scheme, sure,
but I didn't know the IDE (and I have the red, blue, and green
Smalltalk 80 books to browse for Smalltalk examples, so I'm
not completely without documentation).  DrScheme had an
example graphics thing I could cut from the doc, paste, play
with.  It was even a little bit buggy, so they could illustrate
how to do something better (also in the doc).  There's a
"scripting" window in Squeak, but it doesn't appear to be
what I wanted, since I cannot type in it, move it, close it,
or change its size.

Datapoint #2 is the Eclipse IDE for Java.  It took me
a while to figure out what was what, but I made some
progress from the very start, and soon enough I knew
enough to see that I would not have to take anyone
else's word that it would eventually be worth my while
to learn it.  And yes, I am aware that Eclipse has Smalltalk
roots, and I wonder if this turning-over-rocks sort of
user interface is part of the Smalltalk style, because
I have similar gripes about it.  At one point, after
using it for some days, it still took me *minutes* to
find the proper button to push to get what I wanted.

Please understand (and I can see how it would fit your model of
the world not to believe this) I am actually trying to figure
this out, and I am actually quite good at figuring things out.
I've fixed Other People's Bugs in everything from Gosling Emacs,
to device drivers in the LSI-11 FuzzBall OS, to a DVI-to-PDF
converter in MikTeX, to David Gay's floating point-to-string
conversion code.  If it's not easy for me, you've got a problem.
This feels like an Adventure Game, not a user interface.

>I know, but I don't see why not. Squeak is great for writing a wide
>variety of compliers. You've not done it, I take it.

I've written a number of compilers, looked at many more.  I've
written a fair amount of code in Lisp and BCPL, and had quite
good luck with some untyped C code that I wrote long ago (all
roads lead to void *).  I spent a good long time playing with
functional languages (wrote an FP84 interpreter in BCPL, even).
I'm not stupid, I'm not inexperienced.

The compilers I was thinking of, and I should have made myself
clear, seem to take at least 8 person-years to complete, and are
commensurately large.  It would be a tremendous win to write one
of these in less time, but it would also be an expensive experiment.
I don't know if they are large because they must be large, or if
they are large because the use of a stupid language makes them
large, or if static checking makes it possible for them to become
large.  Again, an expensive experiment to determine what's really
going on, and I'm not really interested in ridiculous dogmatic
answers from people who haven't even done it in the "wrong" language.
You probably think I'm a neanderthal for using sucky Java, but
most places I know of that are writing compilers, are using C
or C++ -- they're not even using language with garbage
collection.  (Gcc, astoundingly, is written in K&R C.)  They
are not even willing to risk that minimal a change.

What I don't see is what your purpose in arguing with me like this
is.  My suggestion/request, if you wish to do something about
the adoption of Java where you think Squeak would do better,
is to show off Squeak where it works well, and is clearly better
than Java.  If you wish to argue that Squeak is truly better
even for writing compilers, you can say that, but as a
compiler-and-other-things writer, I see Java's limits most
clearly when working on things that are not compilers.   I think
you are making the job of promoting Squeak (to, for instance,
Apple) unnecessarily hard if you insist on trying to show it off
where Java does not most clearly suck.  Swing's a pig -- it ought
to be easy to make it look bad.

Furthermore, nobody has ever said "wow!" about a compiler demo.

David Chase