Programming with Tuples (was On Reuse) - still reuse

Terry Raymond traymond at ids.net
Mon Jul 5 02:23:31 UTC 1999


On Fri, 2 Jul 1999 23:13:16 -0700, Dan Ingalls wrote:

>"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.

Well, I guess my problem is related to the number of chunks.  Frequently,
when I am trying to understand a complex operation that has been highly
factored I end up with a large number of methods I have to put together
in order to understand the whole picture.  Even if the methods are well
named to permit chunking, many times the problem is that some leaf method
performs an operation that is depended upon by some other leaf method.
This requires one to develop an relationship model among the methods.
However, if all the small methods were defactored into one large method
the dependencies frequently become much more apparent.

Maybe, the problem is that we can factor only on one dimension and
complex problems involve many dimensions.


Terry Raymond
Crafted Smalltalk
(401) 846-6573    http://www.craftedsmalltalk.com





More information about the Squeak-dev mailing list