On Jan 31, 2008, at 12:27 , Blake wrote:

> On Wed, 30 Jan 2008 22:59:54 -0800, Jason Johnson <jason.johnson. 
> 081 at gmail.com> wrote:
>
>> On Jan 31, 2008 3:58 AM, Blake <blake at kingdomrpg.com> wrote:
>>>
>>>         You say this almost like it's a bad thing. It's only bad  
>>> when people do (a), and if they do (a) anyway,
>
>> I think doing (a) is a bad thing.  Anyone can do (a) to a new
>> technology (I know I have, even to Smalltalk once upon a time),  
>> and to
>
> Indeed, we agree.
>
>> me that means they are not ready to look at it.  Moving the wall only
>> changes what they complain about.
>
> Also agreed.
>
>> If one is too accommodating one
>> ends up changing Smalltalk to be source file based instead of image
>> based so newbies understand what's going on better.
>
> Squeak isn't source file based, and I doubt any form of  
> presentation could make it so. (Though, I guess maybe if you had  
> the Smalltalk OS, it would probably host something like a source- 
> file based scripting system. Or something.<s>)
>
> I'm talking presentation and navigation. And it's come up as I've  
> wended my way through the Laser Game tutorial. It actually inspired  
> me to try to come up with a modification that would make building  
> tutorials a lot clearer and easier.
>
>> That sounds to me like an indication that the Smalltalk browser needs
>> some of the keyboard shortcuts your other environments have.  I
>> suppose you achieve some of this by simply dumping a bunch of methods
>> in one text area, but wouldn't it be better to attack the root of the
>> problem?
>
> Well, look, I'm not one to turn down hot keys. I think Bert and I  
> must operate in very different ways, and it wouldn't surprise me to  
> find that there are many different styles of coding. (Or maybe  
> there are just two: Bert's and mine.<s>)

I'm not entirely sure how my name got dragged into this conversation  
- but I do agree with the rest of your post. Setting up a context  
that lets you focus on what you're currently working on is helpful.  
There should be a browser that just shows your "working set", like a  
couple of packages that make up your application. I used such a  
browser framework 10 years ago (Application Management Browser IIRC)  
and it worked nicely, basically each tool had a little checkbox  
switching the filter to your current app on and off. Very handy.

What I find is that experienced Smalltalkers blend out those  
distractions mentally, they only "see" the interesting parts. For  
them it's easy to spot the one interesting sender in a list of a  
hundred methods, or the stack frame in a debugger 10 places from the  
top where the error actually happened. But I also see Newbies being  
overwhelmed by the lack of separation between the system and their  
code. So improved tools are welcome :)

- Bert -

> But the "root of the problem" is visual as well as tactile. It's  
> all very well to have all the source code available all the time,  
> but much of the time, I don't want to have to care. And the  
> remainder of the time, I don't want to see all of it, all the time.  
> I want to see what =I= am working on. More importantly, when I'm  
> teaching, I want students to see =THEIR= code most of the time: I'd  
> like to be able set it up so that the debugger wouldn't go in to  
> the base classes unless asked, because that stuff can be very  
> confusing to a beginner.
>
> One of the most important lessons in programming is that, when  
> you're programming and there's a bug, it's in your own code. Not in  
> the library, not in the compiler, not in the operating system. (If  
> that's not the case, you need a new library/compiler/OS.) I love  
> the encouragement to explore in Smalltalk--I just want to be able  
> to turn it off sometimes.
>
> One nice thing about the debugging stack is that it allows you to  
> flip through the code very quickly. There's a clarity that's not  
> available in the usual object soup.
>
> I recall a study (by IBM, I think) where the amount of code one  
> could see at once was postiively related to productivity. (And yet,  
> I'm the only coder I know with a propensity for conserving vertical  
> space.) I do know that if I'm in method A and it calls method B,  
> and method B is right there? I'm golden. As a corrolary to "the  
> problem is in your code", there's also, "the problem is mostly in  
> the code you just changed". I could see a browser where the methods  
> highlighted their latest changes, like a mini-diff--something also  
> good for pedagogical purposes.
>
> None of this is actually opposed to the Smalltalk philosophy, which  
> encourages the writing of small methods precisely because they're  
> easy to understand. Great. Now let me see more of those little  
> methods, without the real estate needed to make every browser  
> window as effective at browsing the entire universe as it is  
> browsing my code.
>
> By the way, it was my experience with the laser game tutorial that  
> brought a lot of this home (both doing it and watching others). For  
> example, it doesn't leap out at you from a screenshot of a method,  
> whether that method is class- or instance- side. It was always  
> something extra to check--whether that "class" button was a  
> slightly darker shade of green.
>
> 	===Blake===
>