> From: Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se>

[snip]
> It is true; we're back at the Turing machine--there's nothing more  
than the
> Turing machine, ever! But the fault of this reasoning is that it  
only sees
> the formal computer science aspect of the issue. The breakthrough
> contributions of both Simula and Smalltalk took in ideas from  
outside CS;
> it's all about how we *think* about these things; that's the  
improvement.
> And this improvement is in no way a "just". Somehow I never hear  
CS people
> complaining that procedures are really just Turing tapes with  
funny layouts!

Complete agreement!

> To repeat myself, aspect weaving would consist in specifying completely 
> general tangling rules/methods etc., which are in the aspect weaver, 
> separate from and thus invisible to the code itself so to speak.

This is where I disagree, and to me this statement also seems to  
contradict the paragraph above it:  AOP can be *implemented* by  
completely general tangling rules/methods etc.   This completely  
general weaving is, in a way, the Turing machine of code composition,  
the most general possible code morpher.  However, aspects are not  
completely general, they are in fact fairly specific.  (Simple proof:  
 a module is not an aspect, therefore aspects are restricted  
compared to the unlimited transformations possible for a fully  
general weaver).

The AOP people have been using such fully generic  
(algorithmic/procedural) code-weaving tools because the theory hasn't  
yet advanced to a state where the restrictions can be formally  
defined and turned into a tool.

> The "idea" or concept, separation of concerns,  wasn't invented by  
Dijsktra.
> It really just means "breaking the problem down into parts", so  
that you can
> carry out the solution in separable steps instead of all at once.
> Inheritance, encapsulation, data structure, procedures, records,  
modules,
> etc. etc. area all means for separating your concerns. (The  
concept itself
> was--no surprise--formulated at least as early as by ancient Greek 
> mathematicians--I have the URL to the original text :)

[more snippage]

> It is my pet peeve that progress in programming languages is entirely a 
> non-CS endeavor; it's about tools for thinking, from the CS point  
of view
> it's just sugar on the Turing machine. I don't know how much  
Nygaard and
> Dahl realized that their contribution was non-CS in this sense,  
but as we
> all know it was quite explicit in the work on Smalltalk. (And did  
we ever
> thank the Smalltalk inventors here for how much more *fun* they've  
made our
> lives by taking this view?)

Exactly!  Once again, I would say that general/procedural code  
weaving is the "turing machine of code composition".  AOP is  
definitely sugar on top of that.

> > MI, mixins, method combination and even subject oriented programming 
> > (Ossher et al) etc. are markedly different.  Although they all
> > combine code fragments in one way or another, they all yield a
> > localized result.
>
> Well, on the conceptual level at least, they are the same.  
Subjects see only
> certain aspects of an object.

They're definitely not the same.  Take the image-processing library  
example.  There is no way SOP can produce these transformation, which  
move code about instead of just composing it.  SOP is in a way an  
instance of AOP, although it offers a more specific theory of  
composition that isn't completely captured by AOP.  I've been  
following SOP, and although the ideas are very strong, it seems to be  
faltering at the point where automatic composition of methods from  
different subjects is required.  We simply don't know how to work  
this yet.

> With a localized result I believe you mean that code is placed in  
the woven
> method, as opposed to being called somewhere else.

No, that's just run-time vs. compile-time weaving.  MI and mixins  
turn the inheritance tree into a graph, but it's still  
two-dimensional.  Aspects open up orthogonal dimensions, potentially  
affecting every node in that graph at once (but also with the ability  
to target specific parts).

It is true that it is possible, in a way, to project all these new  
dimensions back onto the plane, but you get a much more complicated  
graph as a result.  ( aspects vs. tangled ).  Of course, this is what  
happens when the code finally gets executed.

The issues of orthogonal dimensions, "turing weaving" and the  
difficulty of composition of arbitrary generaly purpose code also lie  
at the heart of the AOPers' preference for special purpose aspect  
languages, I think.  In order for orthogonal composition to be truly  
workable, the languages in use must have well defined (and  
comprehensible!) compositional semantics, which is possible for some  
of these restricted languages but quite beyond our capabilities (and  
maybe even impossible in principle) for generic procedural/imperative  
languages.


Marcel