Consider all the things a programmer needs to keep track of while writing code:
1) Correctness: making sure the program does the right thing, satisfies all requirements, maintains all important invariants, performs the business logic in the desired way, etc.
2) Efficiency: the program uses a minimal amount of time, memory, and resources. This includes not holding onto memory for longer that it is needed, and not releasing the used memory in a fragmented state if possible. Some programs have "real time constraints" where certain efficiency goals, like returning a response to the user within 0.2 seconds, are considered part of their correctness.
3) Debuggability: when things go wrong with the program, it shouldn't be too hard to find out what they are and how to fix them.
4) Maintainability. The program should be documented and readable. It should be written in an internally consistent style that should also match the style of any external codebase it is a part of.
5) Testability. The program should be written in a way that unit and integration tests are both helpful and not too difficult to create.
6) Logging. The program should produce a usually non-comprehensive trace of its execution path and variable state that facilitates its debugging, allows its efficiency to be monitored, and allows for the collection of statistics regarding its behavior.
7) Security. The program should let the user take only authorized actions; typically these are the actions that the user could already perform without the program plus possibly a small set of explicitly defined actions that the user is granted by having access to run the program.
8) Extensibility: small numbers of small changes to the program should be relatively easy to make.
9) Privacy. The program should not reveal data about one user to any other person – possibly including the people who own the program – unless this is explicitly desired.
10) Dependency management. Most programs use code written by other people and other organizations, often in the form of libraries. The programmer needs to ensure that their use of these libraries is legal – i.e., does not violate any license the external code is shared under – and that collective set of libraries are cross-compatible – i.e., if library A uses library C version 1 and library B uses library C version 2, then the programming system either needs to support that [most don't] or situation needs to be resolved. The programmer also needs to ensure that none of the used libraries violate any of the other considerations in this list.
11) Deployment. Many programs are run somewhere other than the computer that the programmer wrote them on. This usually requires work by the programmer to enable, be it by having the program detect and adapt to the environment its running under, or containerizing it to run in a standard environment can be reproduced elsewhere, or writing another program to transform the original program for the new environment.
12) Monitorability/Observability. Not every program needs to worry about this, but long running programs will want the sort of information described under logging available in real time under a separate interface.
13) Persistence. Not every program needs to worry about this, but long running programs will often need to be stopped and restarted and almost all programming systems, the restarting part requires the programmer to do extra work.
14) Input validation. Not every program takes input, but most do, and when they do, they typically need to perform checks to make sure that the input follows the expected or required format, and/or can be converted to that format.
15) Error handling: when things go wrong, the program should degrade gracefully, by logging the error, alerting the correct set of users, and returning the program to an acceptable state.
16) Internationalization and localization. Not every program needs to worry about running in more than one country or communicating to users in more than a single language, but many do.
17) Accessibility. Again, not every program needs to worry about this, but many do need to accommodate users with different physical or mental capabilities, and to do so in a graceful manner.
I could go on, but I think I've made the point that that that's a lot of things, and it doesn't even include things the programmer needs to do while not writing code (such as estimating schedules or communicating with coworkers). Aspect Oriented Programming (AOP) was an idea pioneered by Gregor Kiczales and others at Xerox Parc in the mid-1990s that maybe programming would be easier if the programmer could concentrate on each of these separately one at a time, instead of all together at potentially each line of code.
I've always loved that idea, but I've also always hated the specific mechanism that AOP chose to implement it with – something called the "join point model" which basically amounts to runtime pattern matching on a program's call stack and running some code every time a pattern matches. For example, every time the call stack has a file open routine as the thing that was most recently pushed onto the stack, the program might log the name of the file that is about to be opened. As the Wikipedia page on AOP points out, this is very close to the "COME FROM" statement that was non-seriously proposed as a joke, and equally hard to debug and maintain.
But thanks to the newfound coding capabilities of LLM's, I think AOP deserves another look. In its new form, the programmer need only write separate documents for each concern. The documents will be of very different lengths, of course, with the correctness document typically being the longest. Many of the documents can be re-used and shared across projects; for example, an organization's style guide can be used for the maintainability concern. And the "weaver", to use the AOP term, is simply the LLM that generates the program from the documents.
Why is this better than AOP's old join point model? Well, that model was brittle: to log after every file open, it required matching against a specific string name or set of names for the file open functions. And if a coworker came along and added a new file open function (or worse, renamed one) that wouldn't get logged. Here, with the LLM doing the weaving, we are relying on its background knowledge of what opening a file is to do the matching.
LLMs also have the advantage that the output of their weave is static (i.e., not computed at the program's run time) and readable. There are some AOP implementations that do "compile-time weaving" like AspectJ's ajc, but they output things like not-really-readable raw Java bytecode.
It's also a bit of an unfair comparison, given that LLMs are going to be used to generate code whether or not they do AOP. My point is merely that AOP's notion of concerns gives us a useful way to organize the sentences that we feed into the LLM. (Or LLMs; one could also feed each concern's description into a separate agent whose job was to critique the code from that angle.)
[Linkpost for https://thomaswc.com/blog/the_return_of_aop.html ]
Consider all the things a programmer needs to keep track of while writing code:
1) Correctness: making sure the program does the right thing, satisfies all requirements, maintains all important invariants, performs the business logic in the desired way, etc.
2) Efficiency: the program uses a minimal amount of time, memory, and resources. This includes not holding onto memory for longer that it is needed, and not releasing the used memory in a fragmented state if possible. Some programs have "real time constraints" where certain efficiency goals, like returning a response to the user within 0.2 seconds, are considered part of their correctness.
3) Debuggability: when things go wrong with the program, it shouldn't be too hard to find out what they are and how to fix them.
4) Maintainability. The program should be documented and readable. It should be written in an internally consistent style that should also match the style of any external codebase it is a part of.
5) Testability. The program should be written in a way that unit and integration tests are both helpful and not too difficult to create.
6) Logging. The program should produce a usually non-comprehensive trace of its execution path and variable state that facilitates its debugging, allows its efficiency to be monitored, and allows for the collection of statistics regarding its behavior.
7) Security. The program should let the user take only authorized actions; typically these are the actions that the user could already perform without the program plus possibly a small set of explicitly defined actions that the user is granted by having access to run the program.
8) Extensibility: small numbers of small changes to the program should be relatively easy to make.
9) Privacy. The program should not reveal data about one user to any other person – possibly including the people who own the program – unless this is explicitly desired.
10) Dependency management. Most programs use code written by other people and other organizations, often in the form of libraries. The programmer needs to ensure that their use of these libraries is legal – i.e., does not violate any license the external code is shared under – and that collective set of libraries are cross-compatible – i.e., if library A uses library C version 1 and library B uses library C version 2, then the programming system either needs to support that [most don't] or situation needs to be resolved. The programmer also needs to ensure that none of the used libraries violate any of the other considerations in this list.
11) Deployment. Many programs are run somewhere other than the computer that the programmer wrote them on. This usually requires work by the programmer to enable, be it by having the program detect and adapt to the environment its running under, or containerizing it to run in a standard environment can be reproduced elsewhere, or writing another program to transform the original program for the new environment.
12) Monitorability/Observability. Not every program needs to worry about this, but long running programs will want the sort of information described under logging available in real time under a separate interface.
13) Persistence. Not every program needs to worry about this, but long running programs will often need to be stopped and restarted and almost all programming systems, the restarting part requires the programmer to do extra work.
14) Input validation. Not every program takes input, but most do, and when they do, they typically need to perform checks to make sure that the input follows the expected or required format, and/or can be converted to that format.
15) Error handling: when things go wrong, the program should degrade gracefully, by logging the error, alerting the correct set of users, and returning the program to an acceptable state.
16) Internationalization and localization. Not every program needs to worry about running in more than one country or communicating to users in more than a single language, but many do.
17) Accessibility. Again, not every program needs to worry about this, but many do need to accommodate users with different physical or mental capabilities, and to do so in a graceful manner.
I could go on, but I think I've made the point that that that's a lot of things, and it doesn't even include things the programmer needs to do while not writing code (such as estimating schedules or communicating with coworkers). Aspect Oriented Programming (AOP) was an idea pioneered by Gregor Kiczales and others at Xerox Parc in the mid-1990s that maybe programming would be easier if the programmer could concentrate on each of these separately one at a time, instead of all together at potentially each line of code.
I've always loved that idea, but I've also always hated the specific mechanism that AOP chose to implement it with – something called the "join point model" which basically amounts to runtime pattern matching on a program's call stack and running some code every time a pattern matches. For example, every time the call stack has a file open routine as the thing that was most recently pushed onto the stack, the program might log the name of the file that is about to be opened. As the Wikipedia page on AOP points out, this is very close to the "COME FROM" statement that was non-seriously proposed as a joke, and equally hard to debug and maintain.
But thanks to the newfound coding capabilities of LLM's, I think AOP deserves another look. In its new form, the programmer need only write separate documents for each concern. The documents will be of very different lengths, of course, with the correctness document typically being the longest. Many of the documents can be re-used and shared across projects; for example, an organization's style guide can be used for the maintainability concern. And the "weaver", to use the AOP term, is simply the LLM that generates the program from the documents.
Why is this better than AOP's old join point model? Well, that model was brittle: to log after every file open, it required matching against a specific string name or set of names for the file open functions. And if a coworker came along and added a new file open function (or worse, renamed one) that wouldn't get logged. Here, with the LLM doing the weaving, we are relying on its background knowledge of what opening a file is to do the matching.
LLMs also have the advantage that the output of their weave is static (i.e., not computed at the program's run time) and readable. There are some AOP implementations that do "compile-time weaving" like AspectJ's ajc, but they output things like not-really-readable raw Java bytecode.
It's also a bit of an unfair comparison, given that LLMs are going to be used to generate code whether or not they do AOP. My point is merely that AOP's notion of concerns gives us a useful way to organize the sentences that we feed into the LLM. (Or LLMs; one could also feed each concern's description into a separate agent whose job was to critique the code from that angle.)