[aosd-discuss] Dynamic Languages and AOP...

Sat Feb 25 14:23:54 EST 2006

Ron and Pascal,

Let's say that I have two component libraries that represent "regular"
program modules, and five component libraries that define data structures
that may be used to create classes, properties or even methods.  Suppose now
I introduce a new (in my concept 'meta-program' ) program component that
tells by other two "regular" program modules that we need to construct a
class (of previously unknown signature) from the available data structures
(dynamic type creation) AND then also change a security feature through an
aspect that cross-cuts the original regular programs, unknown to the
meta-program.  Do you agree that the above represents an adaptive system?
The aspect has acted upon internal logic to change the way the
meta-program's class is enacted.

The issues here are complex, but not beyond possibility.  We have no
system-wide meta-meta program to validate emergent behavior in this adaptive
system, so I guess I disagree that an executing system is a program.  Is a
broken Turing machine still searching for a stop executing a program?

Ken

---------------------------------------------------------
Kenneth A. Lloyd
Sr. Software Architect
Watt Systems Technologies Inc.
kalloyd at wattsys.com
www.wattsys.com <http://www.wattsys.com/> 

  _____  

From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On Behalf
Of Pascal Costanza
Sent: Saturday, February 25, 2006 12:24 PM
To: Ron Bodkin
Cc: discuss at aosd.net
Subject: Re: [aosd-discuss] Dynamic Languages and AOP...

On 19 Feb 2006, at 05:27, Ron Bodkin wrote:

Hi Pascal, 

When you say

An executing system is a program, and a program that modifies the execution
of a running system can be a metaprogram.

I couldn't disagree more if you are implying that aspects modify the
execution of a running system. They are part of a running system. You appear
to be assuming the point you are trying to make: that aspects are a
metaprogram and not part of a program.

Metaprograms can be parts of a program. Something that is part of a running
system can modify the execution of that very system. There are no
contradictions here.

Yes, join points are events in a running system. They are not bank accounts,
customers or transfers, they are events in the execution of a program. I
don't see how you can get any more "meta" than that. 

Join points are points in the execution of your model. When one says new
BankAccount() that is a symbol that represents creating a bank account in
your model (in code). When I say call(public * BankAccount.*(..)), that
represents the set of public operations on a bank account, and is also a
domain concept.

Sets of public operations of a class that happens to be named BankAccount
are most certainly not domain concepts. Bank clerks don't deal with public
operations of Java classes.

Likewise, if an OO program invokes someObject.transfer(), many early
adopters of objects read that in a metaprogramming way: "it means to take
the class of some object, look up the transfer method in its virtual
function table, and to call it." If you think that way, then you see the
domain as the domain of programs.

That's completely irrelevant. I couldn't care less whether an AOP system is
implemented in terms of source code weaving, bytecode weaving, runtime
monitoring, or whatever. I also don't care how OOP is implemented.

I am only concerned about the conceptual nature of pointcuts.

Yes. Macros in Lisp exist since the 60's, and they are pretty well supported
at least since the 70's. The CLOS Metaboject Protocol exists since the late
80's, and the nice thing is that metaclasses are "just" plain classes, so
all support for plain CLOS can immediately be used for metaclasses as well.

For current advanced development environments for Common Lisp. (Smalltalk is
interesting here in that it allows you to reify the call stack as a linked
list of objects which allows you to implement debuggers completely in
Smalltalk, without the need to refer to some underlying native library.) 

Are you implying that these tools facilititate uses of metaprogramming to
modularize crosscutting concerns in a quantified fashion?

I don't remember this to be the original question. The original question, as
I remember it, was whether these development environments support
metaprogramming - and they clearly do. They don't support AOP, that's
correct.

Macros support surely does NOT meet this need (e.g., if you handle
exceptions with macros, you scatter macro invocations everywhere, unlike use
of advice). The tools support that matters here is the ability to see wide
ranging effects. E.g., if you redefine method execution to first call a
before method, are there tools that can parse and identify where in base
code the metaprogram applies?

Since CLOS already support before/after/around methods, this case is indeed
covered by Common Lisp environments. (But it's probably not quite what you
mean, because there are no pointcuts in CLOS.)

Re: scale of engineering projects, let me rephrase. I acknowledge that there
are a few (<1%) large scale projects using dynamic languages. I just believe
that the vast majority of them use static languages. And perhaps more
importantly, I believe that the scale of median projects tackled with these
languages has been significantly smaller historically. Both of these may be
changing, but I maintain that's been the situation so far.

And why would that matter? For example, a vast majority of software has
probably been written in languages that don't have built-in support for
garbage collection. Should we question the value of automatic garbage
collection because of that? 

If you want to know whether an approach is scalable, it's sufficient to have
a decent number of large-scale systems implemented with that approach. It
doesn't have to be the "vast majority" of systems to make a point.

That statement would have been true ten years ago, but clearly it isn't now.

That's nonsense. If this were true, we'd be programming in Fortran and
COBOL.

But the proposed argument about GC would be analogous to arguing that
metaprogramming is not useful, which I never said. Instead I am arguing that
there has been limited experience scaling dynamic languages, so it's not
surprising there isn't yet a growth of interest in tools like AOP. You would
need to have several similar large scale systems to reward investing in the
structure required to have AOP rather than ad hoc metaprograms. I think
degree of use matters a great deal when you look at what tools a community
needs. Your analogy of using GOTO versus structured control flow constructs
is apt: the FORTRAN community went quite a while suffering from GOTO before
they realized the need for better structure.

My impression from talking to people in the Lisp community is that their
typical reaction is rather that they can immediately see other ways to
achieve similar effects to that of AOP with means they already know. They
typically have Lisp-style macros in mind here. It's indeed the case that you
can quite a long way with Lisp-style macros until you recognize important
differences between macro programming and AOP. (Yes, this includes
obliviousness, at least to a certain extent.)

It's absolutely possible that AOP is more suited for a static language with
irregular syntax, like Java, while in dynamic languages with more regular
syntax, other solutions are more appropriate.

Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://aosd.net/pipermail/discuss_aosd.net/attachments/20060225/e7716cca/attachment-0001.htm