Re: [langsmiths] Aspect Oriented Programming (AOP)
- On Sunday 30 June 2002 16:20, mike_ekim wrote:
> Well, I just dove in and studied AOP until it clicked. <click> :)I have a lot of material and links about this.
> It seems a natural evolution, but is kind of clunky for staticMany AOP experts would disagree with me, but I think that if you can get
> languages such as Java or C++. It is MUCH easier, and in my opinion,
> saver, to do it in Objective-C, Smalltalk, Ruby, Io, etc. All you
> really need is a proxy object, to do whatever is needed for your
> aspect (security check, logging, tracing, business rule, etc), and
> make each instance require a proxy. I already had this in mind for a
> language, now I can associate an acronym with it. :)
by without a "weaver" then you are doing meta-programming and not AOP.
Which is great if it solves your problem.
Besides the traditional static/dynamic typing, class/prototype
organization and other such divisions, one important difference between
languages that is often overlooked is between what I call "living
systems" and "blueprint systems".
A blueprint system (BP) is entirely defined by its source code. A living
system (LS) accumulates stuff during its execution and can't be shut
down without loss of information. Of course, by saving a copy of the
memory to disk and then restoring it later you can freeze/unfreeze a
LS, but there is a difference between making it sleep and killing it.
As an example of what I mean by LS think of one of your cells. The DNA
in it doesn't have the full source code to build another cell, but it
doesn't need it since the code for "copy this organelle" plus an actual
instance of different organelles is enough to get the job done.
Many hard problems in LS have easy "solutions" in BP. A memory leak, for
example, will eventually kill a LS. In a BP you just have to restart it
once in a while and you get all your memory back. So most simple
systems tend to start out as BP as possible, but as they get more and
more sophisticated they tend to become more LS-like with complicated
configuration files and registeries.
But some things make a lot more sense in pure BP:
1) declarative programming - a blueprint makes a good timeless
description, but something defined by its history is better described
2) macros - when you have clearly separated code expansion, code
translation and code execution phases this is a very powerful tool. In
a LS when a macro is run can be very confusing and the source has a
reduced role anyway.
3) aspects - the code is written separately and then must be weaved
correctly before translation. What was said about macros is also valid
I think this difference is more important than the programming languages
themselves. Scheme is an attempt at a more BP-like Lisp, ANSI Smalltalk
with its purely declarative system definition syntax is a similar
effort, and in ColorForth there is a mostly BP usage style in what
might otherwise be a LS.
So it is no coincidence that the bulk of AOP research has focused on
statically typed languages, but because they are BP and not because
they are statically typed. Most scripting languages are also BP despite
being dynamically typed (Ruby and Python), so I think AOP would be a
great enhancement for these as well.
Since my own focus is on LS many people become frustrated that I don't
"get" macros, AOP or declarative programming. The truth is that I like
them very much and use them when I can. But they are not the right
tools for every job. Before detailing your language, think about the
kind of system (BP/LS) you want to build with it and then choose the
best tools to do it.
Jecel Assumpcao Jr <jecel@m...> wrote:
. . .
> A blueprint system (BP) is entirely definedThank you for articulating the terms in which we can
> by its source code. A living
> system (LS) accumulates stuff during
> its execution and can't be shut
> down without loss of information.
talk about the important distinction between blueprint
and living systems.
Like you, I am interested in living systems.
. . .
> But some things make a lot more sense in pure BP:I tentatively disagree. I feel that a declarative notation
> 1) declarative programming -
> a blueprint makes a good timeless
> description, but something defined by
> its history is better described
will fit in a living system, and that is what I am attempting.
From the outside, via the typical programmer/operator interface,
a system may look substantially "imperative" in that it will
appear to have named mutable stores that the operator can
modify by entering commands. However, the notation within each
method will be declarative.
In a system such as I am attempting to define, a problem comes
up of how to view software, i. e., named pieces of code. It
should be possible to change code. Therefore software is
mutable. But the code for some immutable object (value) is
likely to refer to named software. Should the code that refers
to software treat it explicitly as a process, i. e., a mutable
object? My answer is to say no, within the context of a piece
of code, for purposes of applying the principles of declarativity,
I'm going to pretend that named software is immutable. But in
the underlying implementation of the real system, the software
will be mutable. The evaluation of the application of a named
function to arguments may result according to the old or new
version of the named function, depending on when the evaluator
happens to reduce that part of the graph. In fact, the system
might behave as though the result had come from the old
calculation, but after a crash and recovery, might use the new
. . .
- On Wednesday 03 July 2002 13:12, Jack_Waugh wrote:
> Jecel Assumpcao Jr <jecel@m...> wrote:Yes it does - I was simplifying things quite a bit. In fact, all Prolog
> > [blueprint system (BP) is better for declarative programming]
> I tentatively disagree. I feel that a declarative notation
> will fit in a living system, and that is what I am attempting.
systems I have seen (except for Borland's Turbo Prolog) could be
considered living systems since you could reflectively change the
database as well as save/restore it.
My point is that certain programming tools/paradigms/styles want to
either eliminate change or formalize/restrict it.
> From the outside, via the typical programmer/operator interface,Sounds like a very reasonable goal.
> a system may look substantially "imperative" in that it will
> appear to have named mutable stores that the operator can
> modify by entering commands. However, the notation within each
> method will be declarative.
On a related subject, it is interesting to see how declarative and
imperative notations mix in hardware description languages like VHDL
and Verilog. There we might consider that the declarative parts are the
low level stuff and the imperative the more abstract, which is exactly
the opposite of what we are used to.
> [ named pieces of code.... mutable? ]I think mutable/immutable is a relative thing, just like
temporary/permanent. We fool ourselves otherwise by creating things
like "const" declarations or adding immutable bits to object headers.
The problem is easily ignored in blueprint systems, but must normally be
faced in living ones. Consider the Self compiler: is code immutable?
Most of the system treats it as such - optimizations such as inlining
would not be possible otherwise. But certain tests must be inserted to
verify that it is indeed constant. If they fail, then we must invoke
complicated procedures to undo our optimizations and all their side
effects and try again with the changed code. Osborn's Law: Variables
won't; constants aren't. We must consider them no more than very good
Thinking carefully about how parts of a system see changes in other
parts is what leads us to fun things like transactions, versions and so
on. I started thinking really hard about this in 1984 and only in the
past year have become less than totally unhappy with my designs...