I wouldn't scare people that much^^;

  In regards to printing the hierachy, it is more like printing a web
site.  You usually don't print a whole site.

  Speaking of poking and prodding, I would point out that there is
nothing wrong to plan things upfront.  In situations where planning
upfront makes sense, you should do so.  The good thing about
late-bound languages is that while you can plan things upfront, you
can also poke and prod the live objects, and change the plan whenever
you want.

  To me, late-binding is not just delaying desisions; but it is to
give more options.  That allows the user to make decisions at right
time, (including a decision to revert previous decisions.)

-- Yoshiki

P.S.
Enough ranting.  Need to go back to hack a C++ system on Windows...

At Mon, 6 Dec 2004 23:04:53 -0500,
Colin Putney wrote:
> 
> 
> On Dec 6, 2004, at 10:20 PM, Yoshiki Ohshima wrote:
> 
> > However, the whole point is that you can "do" various things with
> > the Squeak browser.  You can get a subtree quickly.  You can retrieve
> > the "users" of a class, or the classes refer to the class.  Etc., etc.
> 
> Aaron,
> 
> I think the above comment goes to the heart of the (no doubt 
> frustrating) responses you've received to your questions so far. You've 
> been asking for depictions of Smalltalk in various formats - as source 
> code in a text file, as HTML, as UML, as class inheritance diagrams. 
> Although some of these things do exist or could be created with a bit 
> of work, they're generally not in good repair because we, the Smalltalk 
> community, don't use them ourselves.
> 
> In general, we prefer to examine a running instance of the system 
> rather than inert representation of it. Occasionally you'll run across 
> the phrase "live objects." This is what we mean - objects that we can 
> put under the microscope of our development environment, poke them, 
> prod them and watch them twitch and throb.
> 
> The reverse is also true. When writing Smalltalk we don't first create 
> a source code representation of the program-to-be, and then compile and 
> run it. Instead, our development tools are part of the running system, 
> and we work by modifying the program in-place as it runs.
> 
> If you're used to working with representations, this can take a bit of 
> getting used to. The thought of learning how a C program works by 
> trawling through the heap in gdb smacks of masochism, but the Smalltalk 
> equivalent is much more pleasant, and our tools are all designed with 
> exactly this in mind.
> 
> Hope this helps,
> 
> Colin
> 
>