Loading ...
Sorry, an error occurred while loading the content.

Re: [langsmiths] Aspect Oriented Programming (AOP)

Expand Messages
  • Jecel Assumpcao Jr
    ... I have a lot of material and links about this. ... Many AOP experts would disagree with me, but I think that if you can get by without a weaver then you
    Message 1 of 4 , Jul 1, 2002
    • 0 Attachment
      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 static
      > 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. :)

      Many AOP experts would disagree with me, but I think that if you can get
      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
      imperatively.

      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
      here.

      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
    • Jack_Waugh
      In http://groups.yahoo.com/group/langsmiths/message/22 Jecel Assumpcao Jr wrote: . . . ... Thank you for articulating the terms in which we can
      Message 2 of 4 , Jul 3, 2002
      • 0 Attachment
        In
        http://groups.yahoo.com/group/langsmiths/message/22
        Jecel Assumpcao Jr <jecel@m...> wrote:
        . . .
        > 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.

        Thank you for articulating the terms in which we can
        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:
        >
        > 1) declarative programming -
        > a blueprint makes a good timeless
        > description, but something defined by
        > its history is better described
        > imperatively.

        I tentatively disagree. I feel that a declarative notation
        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
        version.

        . . .
      • Jecel Assumpcao Jr
        ... Yes it does - I was simplifying things quite a bit. In fact, all Prolog systems I have seen (except for Borland s Turbo Prolog) could be considered living
        Message 3 of 4 , Jul 3, 2002
        • 0 Attachment
          On Wednesday 03 July 2002 13:12, Jack_Waugh wrote:
          > Jecel Assumpcao Jr <jecel@m...> wrote:
          > > [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.

          Yes it does - I was simplifying things quite a bit. In fact, all Prolog
          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,
          > 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.

          Sounds like a very reasonable goal.

          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
          hints.

          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...

          -- Jecel
        Your message has been successfully submitted and would be delivered to recipients shortly.