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