Living happily together

Jim Benson jb at speed.net
Mon Jul 9 08:18:28 UTC 2001


Lex,

Do the text editors appear beside the lists in this scenario?

>
> 2. Titles are equally important to all morphs, at least under my usage.
>  This is especially true if you use the default color scheme, so that
> you can recognize windows by their color.
>

Does this mean show titles always, or never show the titles? If the answer
is show titles, what do they look like?


Overall, how would you compare this browser with something more structured
such as Whisker, and how do you envision such tasks as integrating the lint
and refactoring browser tools in to this gui?

The dichotomy I see here is that this gui has a very lightweight feel to it,
which I like. The direct manipulation part is very seductive. As you can
guess, the left pane of a class browser means very little to me (as does the
third). I usually start browsing by executing (command-b) on a class name in
a Workspace. I don't find lists as long as the class category is to be very
useful to me. Don't get me wrong, I like having that information available,
but in day to day coding I rarely use that list other than to scroll to the
end to find my code that I'm working on.

Your gui sounds nice for working on several methods here and there. On the
other side, let's say you're working on a project that has about a dozen
classes. The current browsers don't handle that as well as I'd like, and my
first guess is that a more lightweight process would be less helpful.

In some sense, I get the feeling that I need (at the very least) a coding
equivalent to a word processor. A word processor checks for spelling and
grammatical mistakes, so should my development tools but in a different
context. It has to compile it of course, but it should also do lint checking
and make sure I don't make the 10 stupid Smalltalk mistakes. Ideally it
would know other thing too. Like when I've made algorithmic errors ( On2 vs
On for example ) , knows of a better algorithm than the one I'm using, or
has a better 'pattern' for some spot of code, but obviously all that's
somewhere down the road.

As I see it, the current browsers do a smashing job of classifying the
system into named categories. What it doesn't do is tell me how the various
classes interrelate. While I hate to use the term 'CASE tool' , it's
difficult at a glance to tell what the design intentions behind a small app
are (or even what the apps are ;-) and how the classes are related. Even
simple apps require that you have more 'image' specific knowledge than is
reasonable to expect.

Take Celeste as an example, which I would consider a medium to large sized
app. I've never wandered over to look into the code, but I know that it
would take me quite a while to figure out what classes it uses, how those
classes are interrelated, what types of messages get passed back and forth,
and which messages are important. Yet I know when the first pioneers set out
across the plains to write it, they knew all of those things. I also know
there are a whole group of people who have waded through that code and
'rediscovered' how it works.  Knowledge loss of this type is very
disappointing, and creates busy work with no real gain. The followers always
feel like they don't have a complete understanding of the code, and hope
that there are golden nuggets just waiting to be unearthed (even if there
are none to be found). While I don't expect the learning curve to be zero in
such a situation, it shouldn't be 100% either (make that 200% if you have to
learn what's in the rest of the image to begin with). This whole process
needs a formalized tool to help organize classes in a different dimension,
which of course would provide a natural hook for better documentation. I'm
thinking that if you had an organizational tool like that, the 'browsing'
experience could become just as lightweight as you describe.

Jim





More information about the Squeak-dev mailing list