How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?

Available on SqueakSource..
 MCHttpRepository
    location: 'http://www.squeaksource.com/TracingMessagesBrows'
    user: ''
    password: ''
 

----- Original Message ----
From: stéphane ducasse <[hidden email]>
To: The general-purpose Squeak developers list <[hidden email]>
Sent: Tuesday, May 2, 2006 6:03:09 AM
Subject: Re: How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?


On 1 mai 06, at 17:36, Chris Muller wrote:

> I would like to add the Tracing Messages Browser to this list.
> This browser is great for browsing the flow of code that cuts
> across classes in various packages.  You end up with a single
> window showing the flow of execution instead of 57 windows.

Where is that browser?

Stef

But this doesn't work if you use the Refactoring Browser :(

Chris Muller wrote:
> When you browse Squeak code, one of the browsers you will invariably use VERY frequently is a Methods browser.  This browser appears whenever you browse "senders" or "implementors" of a method, or references to a class or variable, among other things.  It is a two-paned browser, methods list in the upper-pane, code in the lower-pane.

Hello Antony,


AB> But this doesn't work if you use the Refactoring Browser :(

it does work. What you have to do is mark the method in the rightmost
top pane of the RB and press Alt m for implementors or Alt n for
senders. This will open the tracing messages browser.

Can't imagine how to continue without.

(on Win that is don't know how to formulate this in mouse button colours)

Didn't yet manage to enter this into mantis.

AB> Chris Muller wrote:
>> When you browse Squeak code, one of the browsers you will
>> invariably use VERY frequently is a Methods browser.  This browser
>> appears whenever you browse "senders" or "implementors" of a
>> method, or references to a class or variable, among other things.
>> It is a two-paned browser, methods list in the upper-pane, code in
>> the lower-pane.




Cheers

Herbert                            mailto:[hidden email]

Yes it works fine with Refactoring browser, it just doesn't get called because Refactoring Browser modifies methods which call the standard methods browser to call its own VERY unfriendly methods browser.
 
 This might be avoidable if you load Tracing Messages Browser AFTER Refactoring browser, otherwise you'll have to revert a few methods that Refactoring Browser installs which calls its own terrible methods browser.
 
 If you are a new Smalltalker, this would be a good exercise in finding and updating code to suit you.  You can find the methods which need to be changed by using the Command+Shift+e on the text of the menu (i.e., "implementors of...").
 
 To get you started, #implementorsOfIt and #sendersOfIt in ParagraphEditor will take care of the ones when browsing out of a code pane..  Another is CodeHolder>>#messageListKey:from: which will take care of using the hot key invocations from message lists..
 
 This is life in Smalltalk.  The system is open so things sometimes get changed, particularly when it comes to the IDE.  Thankfully, the system is open so at least you can take control of your own software destiny.
 
  - Chris
 

----- Original Message ----
From: Antony Blakey <[hidden email]>
To: [hidden email]
Sent: Wednesday, May 3, 2006 7:40:37 AM
Subject: Re: How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?

But this doesn't work if you use the Refactoring Browser :(

Chris Muller wrote:
> When you browse Squeak code, one of the browsers you will invariably use VERY frequently is a Methods browser.  This browser appears whenever you browse "senders" or "implementors" of a method, or references to a class or variable, among other things.  It is a two-paned browser, methods list in the upper-pane, code in the lower-pane.

On 03.05.2006, at 14:36, Antony Blakey wrote:

> But this doesn't work if you use the Refactoring Browser :(
>

Which version are you using? This is fixed in the 3.9 version of  
course, but I think I fixed it even in the 3.8 version....

Name: Refactory-md.3844
Author: md
Time: 18 January 2006, 5:35:35 pm
UUID: b245755d-19cf-482e-8e06-210d4edbcc42
Ancestors: Refactory-lr.3843

delete the overrides for implementors and senders


> Chris Muller wrote:
>> When you browse Squeak code, one of the browsers you will  
>> invariably use VERY frequently is a Methods browser.  This browser  
>> appears whenever you browse "senders" or "implementors" of a  
>> method, or references to a class or variable, among other things.  
>> It is a two-paned browser, methods list in the upper-pane, code in  
>> the lower-pane.
>
>


 
 

Hello Marcus,


MD> Which version are you using? This is fixed in the 3.9 version of  
MD> course, but I think I fixed it even in the 3.8 version....

MD> Name: Refactory-md.3844
MD> Author: md

I'm using Refactory-md3845.mcz and this definitely needs the keys
while the buttons in the code pane and the context menu of the method
pane (top rightmost) don't.

Don't know for 3844.

And I have previously installed Cees'
Tric-RefractoringBrowser-CdG.9.mcz which gives me only selected
categories.

To make it useful:
Took a 3.8.665 image
loaded  Refactory-md.3844
loaded  Tracing Messages Browser-cmm.19.mcz
Buttons and right mouse menu produce the old method browser
Alt-m and n produce the tracing messages browser.


Herbert                            mailto:[hidden email]

All of which reinforces the original point of the thread. So many things definitely don't "just work" - especially given
that I had no idea if this was a) known to be broken; or b) my config error; or c) broken in my particular version; or
d) fixable by investigating the code.

Not a criticism, just an observation that it's difficult to empathise with a newbie when you are not.

As an aside, I guess this is a significant advantage that e.g. VW has over Squeak.

Chris Muller wrote:

On 04.05.2006, at 14:28, Herbert König wrote:


3845 is based on 3844, so it's the same in this regard.

You are right, the buttons call the strange browser for implementors/
senders
(I fixed in only for alt-m / n, I don't use the buttons, so I did not  
see the problem....).
This should be fixed.

Can you add a bug-report to mantis (Squeak-packages)? I'm not sure when
I can fix it, but I'm happy to add a fix if someone does it.

      Marcus

I certainly understand and agree with that sentiment.  Most things with Squeak seem to require a little sweat to get going.  Heck, a lot of packages don't even present a workspace pop-up suggesting where to start; you actually have to look for code-elements and examine just to figure out where to start!
 
 But many things do "work", some even well.  Its just that packages under development move so fast they quickly become slightly contentious with each other.  I think this problem exists in any technology, but amplified in Squeak commmunity.  I think its the side-effects of rapid commumity development, the wide-openness of the system, and a community still struggling with coordination and money.
 
 But I know we can do better, even just a change to a more-inviting mindset would help tremendously.  I think SqueakMap has the right mindset because it tries to document how to get something working; which version, what should be the expected stability, etc.
 
 I do think we need better "one-click loading".  SqueakMap can do it, its just laborious (but flexible) to post, I tried to resurrect SARBuilder but rapid development and lack of coordination and other code changing under me rapidly..  sigh.
 
 Things *are* considerably better than they were, and I think they'll get better and more stable.
 
 Cheers,
   Chris
 

----- Original Message ----
From: Antony Blakey <[hidden email]>
To: [hidden email]
Sent: Thursday, May 4, 2006 8:38:55 AM
Subject: Re: How does a newbie get past the feeling thay he is trying to understand an elephant whilst looking through a keyhole?

All of which reinforces the original point of the thread. So many things definitely don't "just work" - especially given
that I had no idea if this was a) known to be broken; or b) my config error; or c) broken in my particular version; or
d) fixable by investigating the code.

Not a criticism, just an observation that it's difficult to empathise with a newbie when you are not.

As an aside, I guess this is a significant advantage that e.g. VW has over Squeak.

Chris Muller wrote:

Hello Marcus,


MD> Can you add a bug-report to mantis (Squeak-packages)? I'm not sure when
MD> I can fix it, but I'm happy to add a fix if someone does it.

http://bugs.impara.de/view.php?id=3561

Please check before adding the fix.



Herbert                            mailto:[hidden email]

Maybe this will help someone struggling with this issue. Maybe it won't.

I've been an on-again, off-again Smalltalker for years. I've authored  
or co-authored several books on the subject. I've helped design and  
write two pretty substantial systems in Smalltalk. I'm not an  
engineer by training or discipline but I'm a programming language  
junkie with a pretty decent grasp of object-oriented concepts.

My early experiences with Smalltalk had two fearful faces to them.

One was the notion that I was not creating a simple program which, if  
it broke, didn't do any damage elsewhere in the universe. Rather, I  
was <insert appropriate scary overture music> *modifying THE image*.  
It was kind of like correcting God. I used to pause, my fingers  
poised over the keyboard, as I overrode some method or subclassed a  
builtin class and think, "I'm about to modify the known Smalltalk  
universe. If I screw this up...." And my fingers would fall back onto  
the desk. I'm not kidding about this. It sometimes took me a very  
long time to be willing to start coding even when I was sure what I  
was doing.

The other source of fear derived, for me, from the experience that  
said that it was hard to do basic, simple stuff in Smalltalk that  
would have been a cake-walk in Basic or Pascal, the other languages  
with which I was pretty familiar when I began my Smalltalk  
meanderings (which are far too random to qualify as a journey). Just  
an example. I remember one day thinking I'd write the Basic program  
that was sort of just after "Hello World". It printed out the numbers  
from 1 to 10 alongside their square and cube. Trivial, right? Five  
minutes after I opened and installed Basic, I had it working. Pascal  
took longer but that was because the install took longer and I had to  
learn about compilation. I could not get it to run in Smalltalk/V to  
save my gluteus maximus. I can't now remember all the gyrations I  
went through before I finally threw up my hands and asked for help.

But even after that, I remember a lot of times in which I'd spend  
hours poring over the source for various classes and methods that  
seemed like they might do what I wanted to do if only I could wrestle  
them to the ground, finally locate what I needed and then write two  
or three lines of code in a new method that just worked the first  
time exactly as I intended. But the code-shopping phase of  
programming always seemed like it took too long and I believed it  
took too long because I was incompetent somehow. Why? Because always  
before Smalltalk, productivity was measured in lines of code per hour  
or day. In Smalltalk, the real hard-core coders seemed to be the guys  
who wrote the *fewest* new lines of code per day because they figured  
out how to hook into what already worked.

I finally created this analogy. At least I think I created it. Maybe  
someone else had it before me but I didn't read it. Writing a program  
in every language except Smalltalk is like starting with a pile of  
building materials and building a house. There were some large-
function building blocks and some very small ones, but you took them  
from a seemingly infinite pile of those pieces and you fabricated a  
house pretty much from scratch, following a blueprint whose level of  
detail and sophistication varied dramatically. Programming in  
Smalltalk is more like adding a new office or apartment to a  
skyscraper whose very building fabric has connectors for 90% of what  
you want to do and suitable building supplies to fill in the missing  
pieces. If I build a house, I don't have to worry too much about  
fitting in to some other scheme (other than rules and regulations,  
that is). But if I'm going to create a new office space atop a 3875-
story skyscraper that already has a lot of stuff in place, I'd better  
be trying to fit organically into the existing scheme of things and  
create symbiotically.

Like all analogies, this one breaks at various points, but it does  
draw one to a single and helpful inevitable conclusion. If you want  
to master Smalltalk, spend your first days, weeks and/or months  
(YMMV) studying and understanding the key components of the class  
library. Then go design and write your new apartment of office. It  
will be much less painful, even though it will seem to take a lot  
longer at first.

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Dan Shafer
"Looking at technology from every angle"

Nice post Dan,

> My early experiences with Smalltalk had two fearful faces to them.

> One was the notion that I was not creating a simple program which, if
> it broke, didn't do any damage elsewhere in the universe. Rather, I
> was <insert appropriate scary overture music> *modifying THE image*.

In this case, the image appears to have led to this nervous psyche.
Other systems don't have a live environment for trying and learning.
Instead, you start with a blank text editor into which type a program
and subsequently feed to the compiler or interpreter.  These systems
are so closed off there's little or no chance of any danger, is that
right?

Now, I suppose this could be done with Smalltalk too, but its so ironic
that a primary benefit of the environment is *learning* it through live
experimentation and live program development.  I don't know if this
will help but, "Go ahead, its ok."  :)  As you now know, any changes
you make only modify YOUR image and only in memory (until you save).
So you won't do much damage elsewhere in the universe, so go ahead,
explore!  Once you let go of the fear, I think you will enjoy working
in an image immensely.

> It was kind of like correcting God. I used to pause, my fingers
> poised over the keyboard, as I overrode some method or subclassed a
> builtin class and think, "I'm about to modify the known Smalltalk
> universe. If I screw this up...."

Please pardon the blasphemy but, in your image, YOU are god.  That's
the attitude adjustment needed for people to take control of their own
software destiny.  The mainstream sw industry counters this by
constantly pummelling the marketing tecnobabble, it actually works in
intimidating people and they become afraid just like you did.

Adding a subclass will never cause any problem.  The new subclass is
your "blank slate" you can feel safe to go crazy.

> The other source of fear derived, for me, from the experience that
> said that it was hard to do basic, simple stuff in Smalltalk that
> would have been a cake-walk in Basic or Pascal, the other languages
> with which I was pretty familiar when I began my Smalltalk
> meanderings (which are far too random to qualify as a journey). Just
> an example. I remember one day thinking I'd write the Basic program
> that was sort of just after "Hello World". It printed out the numbers
> from 1 to 10 alongside their square and cube. Trivial, right?

Well, I think "familiar" is the key word here, because this is indeed a
cakewalk in Smalltalk too:

  "print it"
  String streamContents:
        [ : stream |
        (1 to: 10) collect:
                [ : n |
                stream cr.
                1 to: 3 do:
                        [ : exp |
                        stream
                                tab;
                                print: (n raisedTo: exp) ] ] ]


Coding time:  2 minutes.  I doubt I could do it in Pascal in < 10
minutes though.  It's just familiarity, thats all.

> Five
> minutes after I opened and installed Basic, I had it working. Pascal
> took longer but that was because the install took longer and I had to
> learn about compilation. I could not get it to run in Smalltalk/V to
> save my gluteus maximus. I can't now remember all the gyrations I
> went through before I finally threw up my hands and asked for help.

When looking at the simple code above, what do you think is the reason
it eluded you so?
 
Code-shopping is no different than looking up in the Pascal manual
isn't it?  Except you can be certain the code is up to date, the manual
may not be..  Also, the code can actually be tried and watch it happen
in the debugger:

  SomeMysteriousClass new halt someMysteriousMethod

> I finally created this analogy. At least I think I created it. Maybe
> someone else had it before me but I didn't read it. Writing a program
> in every language except Smalltalk is like ...

Well, this simply sounds like intimidation by the image again.  Once
you create your own subclass and feel completely free to go crazy, you
can just build your house, right?

> Like all analogies, this one breaks at various points, but it does
> draw one to a single and helpful inevitable conclusion. If you want
> to master Smalltalk, spend your first days, weeks and/or months
> (YMMV) studying and understanding the key components of the class
> library. Then go design and write your new apartment of office. It
> will be much less painful, even though it will seem to take a lot
> longer at first.

I add that "studying" does not have to be reading every class of every
method.  Instead, studying should mean do programming exercises that
force you to "query the database" of code (classes and methods) to
find, experiment and assemble them in the live environment.  This
learning "by doing" should have much more lasting impact than reading
the Pascal manual cover to cover.

Regards,
  Chris

What i note from your excellent point of view is:

- in the image, we are like god (and we like it i guess)

- a good tutorial should teach us that breaking an image is not the end of the
world, we can recover from that. (I am also still afraid maybe because in
early Smalltalk/V, it was not that easy).

- we all need a good step by step tutorial (Dan, i guess you had not access to
the Smalltalk/V tutorial, because your basic example would have been much
easier with this excellent book)

- all the time we spend inspecting the wires down to the power plant when we
just have to install a bulb is the Smalltalk way of building the house. An
investment well retributed by future economy of coding...
This way, we not only reuse our own code, we reuse code from the whole system.

Smalltalk syntax is rather readable, and code is so easy to be changed. So, i
still think the best detailed documentation of code is the code itself. But i
think we lazily rely on that property, and do not write enough documentation.
We rely too much on browsing (i speak for myself). This is not practicle in
modern oceans of code.

As complexity is growing, proper organization (Monticello packages, traits,
something higher ?) and documentation (implementation guidelines and short
tutorials) is a key to Smalltalk success.
And this is valuable not only for newcomers.
Ideally, this documentation would be accessible from the image.
I do not know at which level it should be attached (package ?),
and under which format, but web like navigation sounds good to me, with
crossrefs and links.
The documentation found in squeak projects is something i like. Should
SqueakMap have such projects attached ? Would it be possible to navigate
through such worlds located anywhere on the web ? We have to invent the
tools... (is this Croquet ?)

Nicolas

Chris....

Thanks for the great feedback. Glad you found the post interesting.

I did in fact overcome all of this. I am re-emerging into the world  
of Squeak/Smalltalk with tentative steps these days as I evaluate it  
vs. PythonCard as my next development tool of choice. You can follow  
my thinking and my progress in bits and pieces on my blog if you're  
so inclined (http://www.danshafer.com/onemind). I was recording here  
my very early experiences and fears; they are long since dismissed  
and I find that I now have a proliferation of images containing all  
sorts of stuff and experiments. Playing God in the Image is certainly  
fun. (An aside: I'm a spiritual teacher and writer by profession, so  
I couldn't help but turn your note into a little saying. "The Bible  
tells us we are made in the image and likeness of God. In Smalltalk,  
your image is created by a likeness of God." FWIW.)


On May 8, 2006, at 2:30 PM, Chris Muller wrote:

> Nice post Dan,
Well, your result is nothing like I ended up with; you found a much  
more elegant solution (iterating over the exp for example). But note  
that to create that code I'd have to know about the class String,  
streams, collect: (a powerful but really new concept) and the  
raisedTo: method. Not hard stuff, of course, but, as you properly  
say, it's a question of familiarity and only that.

In Basic, it's something like:

repeat with i = 1 to 10
   print i; i*i, i*i*i
end repeat

Essentially the same in Pascal. But note that the "print" statement  
just prints stuff in a predictable place. When I solved the problem  
in Smalltalk, I ended up believing that I needed to use the  
Transcript for output, which involved figuring out how to get one to  
open and print stuff.

Also, I should note that this was my first attempted program out of  
the box without reading any docs. That's how I'd done it in Basic and  
Pascal, so I expected a similar result form Smalltalk. It was my  
familiarity with other environments and my inaccurate expectation at  
work. But I suspect a LOT of folks who encounter Smalltalk do so with  
a similar mind set and walk away bewildered.

Dan

On May 8, 2006, at 3:28 PM, nicolas cellier wrote:

> - we all need a good step by step tutorial (Dan, i guess you had  
> not access to
> the Smalltalk/V tutorial, because your basic example would have  
> been much
> easier with this excellent book)
>
I did in fact have access to it. Later, I wrote three books on  
Smalltalk. But at the time I was just opening the box to see what  
Smalltalk was about, I was too impatient to read a book. I  had this  
experience in Basic and Pascal and figured I'd give Smalltalk my  
easiest "getting to know you" program as a blind test. That turned  
out to be a wrong-headed approach but at the time I didn't know that.

Dan

On 5/10/06, Dan Shafer <[hidden email]> wrote:

> 1 to: 10 do: [:i |
>     Transcript
>         show: i; tab;
>         show: i * i; tab;
>         show: i * i * i; cr].

Thanks for this, it seems far more comparable from a beginner's point of
view. The other one made me cry. :)

I don't disagree, Duncan. In fact, on some level, the problem I ran  
into is less Smalltalk/Squeak-specific than it is the head-twist  
required to grok a language using objects for everything.

I've since become quite comfortable with all of this, of course (or  
at least I think I have until I try something really sneaky) but at  
first, this was a real wall for me.

Dan

On May 10, 2006, at 3:48 PM, Duncan Mak wrote:

Yeah, in that case, a beginner just needs to grok the idea of a  
Transcript. The iterator syntax looks strange to a newbie but isn't  
hard to read. But I submit that it *is* hard to "invent".

Dan

On May 10, 2006, at 5:43 PM, Simon Michael wrote: