Comment...

From:	Gregor Kiczales 
Date:	Sun, 19 May 1996 17:19:59 -0700

   From:	Cristina Lopes 
   Date:	Fri, 17 May 1996 22:33:53 -0700

   The problem with this text (the Inventor's Paradox pattern text)
   is that it sounds true for many programming
   "paradigms", and not only for AOP. You say about the IP:

   > Solve a concrete problem by solving a more general problem.
   > The general problem has paradoxically a simpler solution.

   AOP => IP, but IP /=> AOP; Therefore, IP is not what AOP is about.

Crista is expressing exactly the feelings I had about the PIP text, but
doing so much more succinctly than I was managing to do!

Let me nonetheless try to add my little bit, hoping it might say a bit
more. 

As it is written, I think the PIP description conflates different levels
of the story surrounding AOP, AP, OI and other related work.  To me, it
is very important to distinguish these levels---that is something I've
been trying hard to do in our work here.

I don't think we've got them completely straight, but let me try to say
something clear anyways!  I want to argue that there is a three-layered
hierarchy of ideas floating around in here.  (Again, this is still kind
of rough, certainly there aren't three completely crisp layers, and no
other possibilities.  I'm reducing it to three because that is enough to
make the distinctions I want to make.)


 FUNDAMENTAL Layer

   This includes the basic engineering approach to problem solving
   (reductionism?) as well as things like the inventor's paradox.

   The basic approach to engineering complex systems is to use
   "abstraction and decomposition to break it down into manageable
   units."  This is an extremely general idea, that applies across all
   engineering disciplines.  But, the cost of its generality is that
   it alone doesn't do much work.  It doesn't say how to think about
   breaking problems up and how to think about abstracting them.

   The inventor's paradox goes a step further, by point out that one
   can often solve a specific problem by solving a more general one.

   A key distinction between this level and the next one is that this
   level doesn't commit to a particular approach to decomposition.
   That is, it doesn't say *how* to break a system down into parts,
   characterize the parts etc.

 DECOMPOSITION PARADIGM Layer

   This level splits into distinct approaches to decomposition.  In
   CS, the primary approach to decomposition has been to break the
   system into "modules" of various sizes.  In other engineering
   disciplines, where the use of both constructive and analytic
   abstractions is more common, they use a variety of decomposition
   paradigms (i.e. both static and dynamic models of simple mechanical
   systems).

 SPECIFIC TECHNIQUES Layer
  
   I'm trying to split this layer off from the one above a bit, mostly
   for conceptual clarity.  This layer is where you get all the tools
   and specific techniques.  Like Fourier transforms, C, succinct
   subgraph specifications etc.

So, in summary, I see a hierarchy of concepts:
                
                 "use abstraction and decomposition"

  "use `functional' decomposition"        "use aspectual decomposition"  ...

 structured programming  OOP  ...        AOP...                        ...



The IP text, as it stands, spans several of these layers.  The basic
idea of the inventor's paradox is at the fundamental layer.  As such,
it applies to all kinds of decomposition paradigms and specific
techniques.  It can be used with functional decomposition as well as
aspectual decomposition.  It is in fact very close -- perhaps
identical -- to the idea of meta-linguistic abstraction that Abelson &
Sussman talk about.

Other parts of the text include ideas from other layers.


To me the AOP project is founded on two things:

 (1) Recognizing the distinction above, namely that:

     - that the prevailing paradigm of `FUNCTIONAL decomposition' is
       just ONE decomposition paradgim,

     - and that lots of complexities in current software systems
       *might* be alleviated with a different decomposition paradigm.


 (2) Developing a kind of decomposition paradigm that works well for
     some of the cases where the current paradigm works poorly.  In
     particular, AOP (and aspectual decomposition) is concerned with
     those cases where if we used a functional decomposition there
     would be important issues that would have to be said repeatedly
     and ALL OVER, rather than in one place.  These are issues that
     cross-cut the executable (the execution modularity).  These are
     what we call aspects.

There's more to say, but already I've take too long to say this.  Next
I want to try to elaborate the little description of AOP in point 2
into a more clear and more suggestive description.

Gregor