From: jfosterk
Subject: expert programmers know how to choose the level of abstraction
Date: 
Message-ID: <K3cn5.6861$2k1.265369@news-west.usenetserver.com>
I was thinking about a paragraph from SICP:

"As programmers, we should be alert to opportunities to identify the
underlying abstractions in our programs and to build upon them and
generalize them to create more powerful abstractions.  This is not to say
that one should always write programs in the most abstract way possible;
expert programmers know how to choose the level of abstraction appropriate
to their task."

Could someone give an explanation of what this means from his/her
perspective?

From: Colin Walters
Subject: Re: expert programmers know how to choose the level of abstraction
Date: 
Message-ID: <87hf8ijyw8.church.of.emacs@meta.verbum.org>
"jfosterk" <········@yahoo.com*spam-prevention*> writes:

> "As programmers, we should be alert to opportunities to identify the
> underlying abstractions in our programs and to build upon them and
> generalize them to create more powerful abstractions.  This is not
> to say that one should always write programs in the most abstract
> way possible; expert programmers know how to choose the level of
> abstraction appropriate to their task."
> 
> Could someone give an explanation of what this means from his/her
> perspective?

I believe there is a quote attributed to Linus Torvalds that goes
something like:

"Trying to be too generic is EVIL."
From: Samir Sekkat
Subject: Re: expert programmers know how to choose the level of abstraction
Date: 
Message-ID: <MPG.1407aca94b18d854989685@news.compuserve.com>
In article <··························@meta.verbum.org>, 
·······@cis.ohio-state.edu says...
> "jfosterk" <········@yahoo.com*spam-prevention*> writes:
> 
> > "As programmers, we should be alert to opportunities to identify the
> > underlying abstractions in our programs and to build upon them and
> > generalize them to create more powerful abstractions.  This is not
> > to say that one should always write programs in the most abstract
> > way possible; expert programmers know how to choose the level of
> > abstraction appropriate to their task."
> > 
> > Could someone give an explanation of what this means from his/her
> > perspective?
> 
> I believe there is a quote attributed to Linus Torvalds that goes
> something like:
> 
> "Trying to be too generic is EVIL."
> 
> 
I think that choosing the right level of abstraction can leed to very 
powerful functionality and might reduce considerably development time.

but at the same time, I try to fight the visionary in me and stick to the 
extreme programming rule:
The most important rule in our development is always to do the simplest 
thing that could possibly work. Not the most stupid thing, not something 
that clearly can�t work. But simplicity is the most important contributor 
to the ability to make rapid progress.

of course as soon as a system gets big enough, often simplicity means 
finding the meaningful abstractions.

BTW the eXtreme Programming people came from the Smalltalk corner
more under http://www.xprogramming.com/Practices/xpractices.htm

Samir, Munich
From: Kent M Pitman
Subject: Re: expert programmers know how to choose the level of abstraction
Date: 
Message-ID: <sfwn1iamozt.fsf@world.std.com>
"jfosterk" <········@yahoo.com*spam-prevention*> writes:

> I was thinking about a paragraph from SICP:
> 
> "As programmers, we should be alert to opportunities to identify the
> underlying abstractions in our programs and to build upon them and
> generalize them to create more powerful abstractions.  This is not to say
> that one should always write programs in the most abstract way possible;
> expert programmers know how to choose the level of abstraction appropriate
> to their task."
> 
> Could someone give an explanation of what this means from his/her
> perspective?

Sure.  It means that if you want to sum up a list of integers, it's reasonable
to suppose that you might at another time make a list of floats, and so to make
a single abstraction suitably broad that your system could use the same 
ADD-THEM-UP routine in both places.  And you might even make it work for
sequences.  But absent special need, it's probably not a good idea to make
a completely general protocol for adding up other kinds of things, perhaps by
creating a generic function MY+ which could be customized to allow you to add
up bricks and other kinds of things.  In some situations, this kind of 
generality might be very important, but unless you know you need it, you should
resist it.

In short form, I would say that generality is the enemy of efficiency.  And
since both generality and efficiency come into play in most cases, the best
thing is to make something as general as it needs to be to suit the 
circumstance, but not much moreso (except to accomodate reasonably anticipated
growth) since all you'll be doing is slowing down either the performance of
the system or the length of time needed to learn its full and unnecessary 
generality.

Dunno if this helps, but hope so.
From: David Hanley
Subject: Re: expert programmers know how to choose the level of abstraction
Date: 
Message-ID: <399D9415.2D4DF023@ncgr.org>
Kent M Pitman wrote:

> In short form, I would say that generality is the enemy of efficiency.  And
> since both generality and efficiency come into play in most cases, the best
> thing is to make something as general as it needs to be to suit the
> circumstance, but not much moreso (except to accomodate reasonably anticipated
> growth) since all you'll be doing is slowing down either the performance of
> the system or the length of time needed to learn its full and unnecessary
> generality.

Ooohh...  My experience is that programmers have such a natural tendency to
grossly under generalize things, that it's better to make code as general
as possible while still having acceptable efficiency, rather than to shoot for
making it only as general as necessary.  That's because all systems evolve,
and that generality is in, um, generally, much easier to move to a new
model/method more than highly specialized "efficient" code is.  Plus, i
generally find more general code easier to understand and upgrade, because
functionality for a specific thing tends to be far more localized.

(to the first poster)

Really, it's power to make general code is one of the, if not the main
reason/reasons I like lisp.  I have some (java) code that has a vector
of many objects, only some of which are visible, and I want to do things
to the visible ones.  In lisp, I could just do this:

(defun map-to-visible( objects function )
    (map nil #'(lambda(object)(when (visible object) (funcall function object))))

And easily do things to only the visible objects:

(map-to-visible-objects objects #'go-left)
(map-to-visible-objects objects #'hide)

Now, this may not have seemed necessary when you were doing it once.
You can just use two loops, no big deal. But then you add another time,
then a fourth, then a few more.  Soon, you're doing it in a dozen places in
the code.  Ok, ugly, clunky, less easy to understand, but it works.
Then you change how the visible function works a bit.  Now,
you've got to track all those places down, or else you get bizarre runtime
behavior. Generally, less lines of code means fewer errors, and
generalization helps you achieve less code in the long run.

dave
From: jfosterk
Subject: Re: expert programmers know how to choose the level of abstraction
Date: 
Message-ID: <ow9o5.42508$2k1.1198691@news-west.usenetserver.com>
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> In short form, I would say that generality is the enemy of efficiency.
And
> since both generality and efficiency come into play in most cases, the
best
> thing is to make something as general as it needs to be to suit the
> circumstance, but not much moreso (except to accomodate reasonably
anticipated
> growth) since all you'll be doing is slowing down either the performance
of
> the system or the length of time needed to learn its full and unnecessary
> generality.
>
> Dunno if this helps, but hope so.

Yes.  This is the advice I needed.

I also appreciated the Xtreme Programming precepts:

When you�re thinking about "we�re going to need this someday", you�re not
thinking about "we need this today". You just distracted yourself from your
goal. Don�t compound the error by chasing tomorrow.

If the object is so complex that it will be hard to modify later, it is just
too complex. Simplify it so that adding new capabilities will be easy, but
don't make it even more complex by adding them now.
From: John M. Adams
Subject: Re: expert programmers know how to choose the level of abstraction
Date: 
Message-ID: <xaovgwydz4s.fsf@anarky.sogs.stsci.edu>
"jfosterk" <········@yahoo.com*spam-prevention*> writes:

> I was thinking about a paragraph from SICP:
> 
> "As programmers, we should be alert to opportunities to identify the
> underlying abstractions in our programs and to build upon them and
> generalize them to create more powerful abstractions.  This is not to say
> that one should always write programs in the most abstract way possible;
> expert programmers know how to choose the level of abstraction appropriate
> to their task."
> 
> Could someone give an explanation of what this means from his/her
> perspective?

I find it worthwhile to consider the distinctions between spender,
investor, cunning investor.  In programming, abstractions are to be
considered as prospective investments.  What do they cost?  What do
they return?

In the final analysis, the expert chooses a level of abstraction
(investment) by understanding a mechanism's relationships with the
things around it.  From this comes the perception of critical
attributes like "frequently used" or "load bearing".  So armed, the
expert considers investments in those abstractions that promise
attractive returns.  The novice struggles to move beyond abstract
principles applied to the mechanism in isolation.  He can see the
technical beauty or ugliness but not necessarily the value of the
product.

-- 
John M. Adams
From: Jochen Schmidt
Subject: Re: expert programmers know how to choose the level of abstraction
Date: 
Message-ID: <8nksa1$91l66$1@ID-22205.news.cis.dfn.de>
jfosterk wrote:

> I was thinking about a paragraph from SICP:
> 
> "As programmers, we should be alert to opportunities to identify the
> underlying abstractions in our programs and to build upon them and
> generalize them to create more powerful abstractions.  This is not to say
> that one should always write programs in the most abstract way possible;
> expert programmers know how to choose the level of abstraction appropriate
> to their task."
> 
> Could someone give an explanation of what this means from his/her
> perspective?


This is similar to what Donald Knuth said upon the negative consequences
of exaggerated optimization.
If we think to much on writing the most efficient code, then we will never 
deliver any code. Only little parts of a project need good optimization.
Unfortunately Knuths remark lead to the common view that all optimization 
is evil - but that is nonsense.
We can now say the same upon building up abstractions:
If we think to much in building abstractions, we never get any real code. We
would possibly have a nice general hull - but no ingredients.
But that doesn't mean that we should emphasize to concentrate on the 
"ingredients".

I think the following is the right way to go:
Optimization:
You should try to be "globally efficient". This means that you choose your 
algorithms right and build up a simple and maintainable construction.
Don't waste time with "Microoptimization". You can "microoptimize" your code
if you have real speed problems and after extensive profiling sessions to 
find the critical sections.

Abstraction:
At some point when designing your project, you are at the situation where
the abstraction-level is at a point where you gain nothing when you would
try to generalize any more. You will notice that you have reached that 
point when it tends to be difficult to derive new abstractions.

-- 
Jochen Schmidt
···@dataheaven.de
http://www.dataheaven.de