"Terry Raymond" <traymond at IDS.NET> wrote...
>On the system that I am working some people have highly factored code,
>which is easier to reuse.  But it is more difficult to understand,
>you have to look at a lot of trees to figure out what the forest looks
>like.

Factoring is certainly good.  In an ideal system, no independent concept or behavior would be implemented in more than one place.

However, in grappling with the reality of end-user programming, it's not clear that maximum factoring isn't the most important thing.  Consider our collection hierarchy:  reasonably well factored from a computer science perspective, but totally overwhelming to a newbie.  Instead consider mashing a lot of this together into a single kind of collection that can do almost all of that stuff with clear protocols for indexing, set operations, streaming, sorting, etc.  This is taking GENERALITY to be the highest figure of merit.  Generality is important because it helps to reduce the number of things you need to learn about, and the number of things you need to keep in your head at one time.  Factoring is still important, of course, and you should see it in the design of the various protocols.

I like the "7 +- 2 rule" metioned earlier in this thread -- that you can only deal with about 7 independent "chunks" at once in your brain.  I think it's even less when any of them has added complication that consumes valuable attention.  That's why it's important for things to be SIMPLE as well as general.

In my ideal computing environment (and we're a long way from it yet), almost anything that goes on could be diagrammed in a picture with not more than 7 independent elements, or understood with not more than 7 pieces of code on the screen.  More concreteness helps, too, as you don't have to use precious "chunks" of attention on what isn't being shown.

I'm a fan of UIs that help to collect the independent aspects that belong together, such as the MVC viewer that shows all three parts at once, or inspector/browsers that let you think of methods and state collected and active together.  For every one of these conceptual nexi, there should be a UI that lets even a newbie contemplate the architecture.

I wish I were better at this myself.  I think the closest I've come is the little diagram at the end of my ST-76 paper that shows how bytecodes, methods, instances, classes, method dictionaries and contexts are all play together in the dance of the interpreter.  But I never made it into a real UI.

Hopefully soon we'll have Squeak to a functional plateau that we're happy with, and we can start working back toward simplicity and generality again.

	- Dan