Aspect-Oriented Programming with AspectJ 496
Aspect-Oriented Programming with AspectJ | |
author | Ivan Kiselev |
pages | 274 |
publisher | SAMS |
rating | Excellent |
reviewer | Verity Stob |
ISBN | 0672324105 |
summary | Introduction to a new programming technique using an extension to Java |
He has divided the book into four parts. Part I provides a brief sketch of AOP and introduces its concepts. AOP builds on OOP, asserting that we need a new programming entity called, wait for it, an aspect. Mr Kiselev's explanation of aspects reminded me of that bit in The Hitchhiker's Guide to the Galaxy when the planet Golgafrincham divided its population into A types (who were the leaders, the scientists and the great artists), the C types (who were the people who did all the actual making of things and doing of things), and the B types, who comprised everybody left over: telephone sanitizers, advertising account executives and hairdressers. As I understand Mr Kiselev, the AOP view of things is that objects and classes (A type thinkers) and low-level procedures and APIs (C type doers) can be nicely encapsulated using traditional components. But aspects, software's little hairdressers, get their fingers into everything, and until now there has been no way to encapsulate them. This of course is what AOP in general and specifically the AspectJ superset of the Java language set out to do.
AspectJ's eponymous aspects are constructs not unlike ordinary classes. Mr Kiselev has not resisted the temptation to make an aspect Hello World example, and it looks reassuringly so-whatish:
package intro;
import java.io.*;
public aspect HelloWorldA
{
public static void main(String args[])
{
System.out.println(Hello, world!);
}
}
Mr Kiselev then lays out his stall of New Things. A join point is any point in execution flow that AspectJ can identify and -- to get slightly ahead of ourselves -- execute some extra code. The most frequently used kind of join point being the call to a method. Pointcuts specify collections of join points; as a regular expression is to an instance of matched text, so a pointcut is to a matching join point. An advice (with horrid plural 'advices') is the code to be executed when a given pointcut is matched. If you are familiar with Eiffel's pre- and post-conditions, then you'll understand if I say that it is common for advices to run in the same way, topping and/or tailing the execution of a method. The differences are that aspects are specified from outside the method without touching the method or its class's code, and that aspects can be applied to multiple methods in one go. Mr Kiselev concludes this section of the book with a few simplistic examples of 'here is class A, here is class B' kind.
In Part II Mr Kiselev rolls up his sleeves and takes us through an extended, realistic example. I did wonder if perhaps it weren't a wee bit too realistic, as it is a miniature website application for news story submission and reading -- sort of Slashdot Ultralite -- all done using JSP and a MySQL database. Just explaining this setup, without even using any AspectJ, consumes a 15-page chapter. Since I am a C++ programmer who has not had any contact with JSP, I was initially anxious that I might not be able to follow this. However, recalling that www.[name withheld].com, the clumsiest, ugliest corporate website on the Internet, is programmed in JSP, I reasoned that if the dolts that programmed that site could understand JSP then it couldn't be very hard. So it proved.
The first example comprises adding password protection to the application. This is achieved by adding an advice that intercepts calls to doStartTag() methods. The advice can test if the user is logged in and, if he isn't, throw an exception that will dump him back at the login page. (Who says exceptions aren't 21st century gotos?) At this point Mr Kiselev admits that the cute 10-line implementation that he initially shows is in reality a non-starter; for one thing not all pages that must be secured define doStartTag() methods, for another the aspect can't reach an instance variable it needs to read because it is declared in protected scope. The second problem is easily overcome. AOP offers a mechanism by which extra classes can be bodged ('introduced' is the preferred verb in the AOP community) into the hierarchy as parents of existing classes. He uses this to add an accessor method for the field in question. The other problem is not so neatly smothered, and it is somewhat ruefully that Mr Kiselev produces his final, two-page solution. But I think that it is greatly to Mr K's credit that he does this - it tastes like programming in the real world as I have experienced it.
For the rest of Part II, Mr K demonstrates other applications of AOP using the AspectNews code. This includes Eiffelish design-by-contract stuff, improved exception handling, various debugging and tuning techniques (specifically logging, tracing and profiling) and a chapter on runtime improvements - stream buffering, database connection pooling and result caching - which show the AOP way to do things, usually where I would expect to be putting in proxy classes.
In part III we get down and dirty with the AspectJ language. This is the part where the book explains the obscure stuff: how to make a pointcut that picks up object preinitialization, or make an advice that goes off only when you are exiting a method on the back of an exception. I skimmed this bit - I guess it will become vital when I start using AspectJ in earnest. It looked good and clear on a flick through. A brief part IV contains some patterns, to give one a start when engaging AspectJ in earnest. Apparently it is horribly easy to create infinitely recursive situations, so if you here a faint popping sound from your machine it will be the stack colliding with the heap. There are seven appendices, supplying such things as a summary of the API in AspectJ's packages and hints on obtaining and using the Open Source supplementary tools mentioned in the book (Tomcat JSP container, MySQL database and Ant make replacement). AspectJ itself, now escaped from Xerox PARC, can be downloaded from the Eclipse website.
Complaints? None really. Oh all right, here's a nitpicklette because it's you: at page 75 Mr Kiselev adopts the irritating Internet habit of writing 'loosing' when he means 'losing'. Note to publisher SAMS proofreaders: do I win 25 cents?
For the rest, this is a lucid and readable book that describes the Next Big Methodology. I'm a bit alarmed at the prospect of squeezing new actions into the cracks of existing code, but I dare say I'll grow to love it.
A word of warning to the eager: since this technology is currently implemented as a species of preprocessor that relies on having all the source code available at once, so it is rather slow and probably isn't going into production shops for a while. There again, I seem to remember the comparable Cfront C++ compiler doing rather well, before we had platform-native C++ compilers.
And to the sceptics: if you think you can ignore AOP, don't forget the fate of the A and C type inhabitants of Golgafrincham, who having sent their B type telephone sanitizers into exile were all wiped out by a germ caught from a particularly dirty telephone.
You can purchase Aspect-Oriented Programming with AspectJ from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Yet another reason to switch to Lisp (Score:5, Insightful)
Once you've used a language like Lisp with closures, macros (at the language level, not wimpy C macros), and code-is-data, it's hard to go back. I feel sorry for everybody who has to use Java, for whatever reason, and will have to get a new language/compiler/libraries just to take advantage of a slight change in "what's hot today".
Re:So, what is this? (Score:3, Insightful)
From what the reviewer talked about with A types, B types and C types, it sounds a whole lot like roles and the delegation design pattern.
Agree? Disagree?
Sounds like pre-post "exception" handling (Score:3, Insightful)
A methodology hasn't made really made it until somebody has published a Proper Book
Are they kidding. Hell there probably books out here on clipping your finger nails using a new methodology. Now days having a book don't mean squat (unless you're a tree, beaver, or a bird).
Re:Where's this useful? (Score:3, Insightful)
D
Here we go again.. (Score:0, Insightful)
wants to make a name for himself. God save us from the egos in the computer world...
This is not good (Score:2, Insightful)
Re:Where's this useful? (Score:3, Insightful)
And of course, INTERCAL has the 'COME FROM' statement.
To sum up (Score:2, Insightful)
Okay, so there are some objects that don't act like objects, so he wants to call them aspects and give them more power and scope throughout an application.
The main concern is while this may improve a program, I see 'aspects' being dropped in favor of meeting a deadline.
My 2 bits... (Score:5, Insightful)
In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.
By and large, the more I work in java, and the more I work in Lisp, I realize how lacking java is in dynamic behaviors. The lisp guys yawned when OO became all the rage because, well, it is so easy to do in lisp. If AOP gets big in java, they will yawn at that too:
"Oh, so functions and try blocks are your boundry block for inserting aspect oriented code? Well, *every parenthisis* is ours. Put that in your JVM and smoke it."
Cheers,
prat
Portable.NET uses AOP for the C# compiler: treecc (Score:3, Insightful)
http://www.southern-storm.com.au/treecc_essay.h
http://www.southern-storm.com.au/treecc.html
h
It is also rumored that Portable.NET will use treecc for the creation of a JIT engine sometime in the future.
From my limited understanding, Aspect Oriented Programming combines the power of the Visitor and Inheritance patterns without the drawbacks of either.
Another interesting link:
http://www.pcmag.com/article2/0,4149,44061
Re:Where's this useful? (Score:5, Insightful)
I'm not trying to troll here, but I'm afraid this might sound like it.... It sounds to me like the main selling points of AOP are that you don't have to design things well in the first place, because if you missed something, well then you can change how your objects behave without redesigning them.
The place where this wouldn't be true is with code that's part of the API or other code that comes packaged. I think that changing the behavior of this type of code sounds pretty dangerous to me - there's a reason that some data is kept in private and protected variables! Wouldn't you get into situations where you've added and aspect or a parent or some such thing, and in the process you access a private variable, and then you upgrade your runtime environment which changes the INTERNAL structure of the code that you hooked into (leaving the external API the same), breaking your code? Isn't that what code encapsulation is for? What I'm hearing touted as AOP's best feature is that you can break encapsulation.... Count me out.
Re:So, what is this? (Score:4, Insightful)
What is Aspect-Oriented Programming?? I've never heard of it!
the gimmick dejour. yet another programming methodology that hopes (in vain) to eliminate the need for skilled programmers.
Once again someone proves the old saying Better to keep your mouth closed and be thought a fool than to open it and remove all doubt. I can see why the above response was submitted anonymously.
The goal of Aspect-Oriented programming is not to eliminate the need for skilled programmers. The goal is to reduce the local complexity of code. Make it so that when you look at code who's job is to store some data, it isn't cluttered with all of the other code like debugging and error handling. The point of this isn't to remove that code all together, but rather to make it much less tightly coupled. Why should persistence code be married to logging code? The answer is it shouldn't, they are two entirely different functions. Aspect-Oriented programming makes it easier to decouple them. This makes both pieces of code more flexible, and reusable.
Re:So, what is this? (Score:5, Insightful)
Basically, imagine if you wrote a program which had "hooks" scattered through it. As you write your code, you place hooks for before/after doing many things: reading user input, transmitting network data, accessing preference files, checking permissions, etc. (Imagine wrapping all your function calls with dynamically-bound functions which you don't yet know if map to an identity function, or have some effect)
Other parts of the program can then hook into these things and effect how your program runs, without them having to go through and modify your code. (Example: if they want to log a message to file everytime your "CastRay()" function is called, they can do this without going in and editing your code).
Now, imagine than rather than the programming having to plan ahead to scatter hooks all around his code (uglifying it towards readers who don't care about them), they are inserted automatically by the compiler.
So a person can create a function which will be automatically called whenever some other set of 3 different functions is called, without having to go modify each one. Instead of going to each function body and adding a call, he at one position attaches his code to functions of that kind. The program is shorter, but has more effects. This may mean, when all goes well, that if someone adds a new function with similar effects, those hooks may still get called.
Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?
In both those cases, the program is doing things that the source code doesn't make 100% clear to a programmer reading a single function body. This can be either good or bad. The usage of editing tools which evaluate the code and alert the reader to these facts (analogous to "class browsers" in several IDEs) shift it much further towards "good".
Re:So, what is this? (Score:5, Insightful)
Aspect Oriented programming is a brand new programming paradign, kinda of like the switch you made when going from functional programming to object oriented programming. It's a different way of expressing your programs
The reason that Aspect Oriented Programming was created was due to "cross-cutting" concerns that cannot be easily modelled in object oriented programming. I read the presentation for AspectJ and the example they used was logging in Apache Tomcat. Bascially the code that is used for logging is scattered throughout the whole program on hundreads of different lines, not all in one nice neat class. Aspect Oriented Programming wants to give the programmer the tools to gather all of this code together.
Bascially, Aspect Oriented Programming is supposed to result in: less tangled code (code that is fragmented throughout your program because you are unable to modularize it well), more natural code, shorter code, easier to maintain and evolve, and more reusability.
One question I had about the book that the review didn't seem to answer was did the book talk at all about designing using Aspect Oriented Programming? Just like Object Oriented Programming, it's a great tool until you get some inexperienced programmer who just knows how to program functionally, and thus doesn't use the advantages of aspect oriented programming. I too would like to learn more about how to go about designing a program in an Aspect Oriented way; such as how to identify aspects, what are some common aspects, etc.
In all, I'm very excited about Aspect Oriented programming. I think it has the ability to allow programming to shape thier programs more naturally, make their programs easier to understand, and make the whole process much eaiser. But of course as with any new technology, it has some growth and refinement to go through yet.
Those of you who would like more information can check out the AspectJ [eclipse.org] webpage, or the Aspect Oriented Software Design [aosd.net] webpage.
Re:I prefer reading... (Score:3, Insightful)
This is from /usr/src/linux/Documentation/CodingStyle
Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.
Re:I prefer reading... (Score:1, Insightful)
This just goes to prove that knowing how to do a good job and actually doing it are two completely different things.
disgusting (Score:5, Insightful)
When will people realise that the most important thing in a programming language is to make it possible to reason about one part of it independent of another part? Most of the time spent developing a program is spent modifying code, not creating new code!
Unfortunately people don't realise this: they just want a way of hacking something existing into something different, cross their fingers and hope that it works when someone changes some other part of the system.
Sadly, it's not just AOP: some of the "usual" OO programming language features suffer this kind of problem too [micro-workflow.com].
Then again, maybe I'm completely wrong, and AOP has a sound theoretical basis and has been created by someone with deep understanding of programming language developments over the last thirty years... someone please reassure me!
My take on AOP... (Score:5, Insightful)
Anybody who has worked extensively in Java has found this problem before. Cross-cutting concerns - you know, those systemic things that infiltrate their way into every module of your humongo-system, no matter how you try to partition it. Now, object-oriented programming, isn't that supposed to let you "blackbox" things so you can just abstract away such things and throw them in some "common" or "system" package and be done with it? Sure, you can. And you probably have. And I've done it too.
But these solutions can be suboptimal - for example, a project I once worked on had an Interface in the com.blah.blah.system package for logging, messaging, persistence, and some other features. These were always nasty pains in the ass to manage. I mean, some implementor of these objects existed everywhere in the system - if something changed fundamentally, or there was some insuffiency in the interface that was discovered, god forbid, you'd have to root around for hours changing code everywhere. Especially when exception signatures changed. Which eventually leads, in sheer frustration, to using Runtime exceptions everywhere, or declaring all of your "system" interfaces with "throws Exception". Ugh. Each solution seems worse than the problem.
Admittedly, problems like this can be solved with good refactoring tools and practices. But not always well. The exception issue for "system" or "cross-cutting" interfaces was one I've never seen solved well (again, I'm thinking of Java here, it's the language I have the most experience working in large commercial-scale projects in where this stuff is really important). If you are working on medium or small sized open source projects, or medium or small sized tools or desktop applications, you may never have come across these kinds of limitations or frustrations in sufficient numbers to justify looking into AspectJ/AOSD in general. But if you've worked on large enterprise software projects, I'm sure you can see that there is a need to "patch," but certainly not replace, the standard OOP methodology to address these kinds of concerns.
Re:I prefer reading... (Score:3, Insightful)
And Code Complete really isn't a bad book at all. It may give you some false starts and misdirections, but it will definitely make you think about aspects of software development methodology.
Re:My 2 bits... (Score:5, Insightful)
In java you can get 50% of the way to AOP using Dynamic Proxies (see java.lang.reflect.Proxy) which allows you to wrap all method invocations or an object. This without an outside tool. This is how a lot of j2ee app servers do thier magic.
Sure, of course you can. AOP is a technique, supported by tools, it doesn't need to be hoodoo magic to be useful. Mind you, like you said, it'll get you 50% of the way. You can get 50% of the benefits of assertions by writing a static Assert class and using it consistently. It's just that it is nice to have capabilities either built into the language to support good practices, or extensions to the language (a la AspectJ) to support them.
And the List thing is tired. We all know that Java is limited. It's limited compared to C++, it's limited compared to Lisp. Ya know what? That's a good thing. For large software development projects with many engineers involved. I can pick up other people's code and not worry about whether X really means X or whether it's a macro that's been defined elsewhere to mean Y. I realize my view on this isn't the most popular on Slashdot, but that's probably because people haven't had to manage teams of developers who aren't populated throughout with brilliant coders, capable of writing fast, functional readable code in languages that leave n degrees of freedom.
Adding capabilities to a language to support a particular kind of new programming paradigm is not unreasonable. I realize that the fact an extension to the language is needed seems like a limitation, and it is, but like I said, that limitation can be a godsend, and it's worth the tradeoff.
Of course, when I'm working on my own time on my own projects, I far prefer to use a manly language like C++, or a pleasant language like Python.
Re:This is not good (Score:2, Insightful)
Maybe it's just me (Score:4, Insightful)
This has the feel to it that the programing methodology is becoming religious dogma, rather than a useful tool.
I've been getting that feel for a while now, as OOP languages start to compete on their "purity" or whether they're "real" OOP languages or not.
I've been programing "Object Oriented" since the 70's. In languages, like APL, that no one would consider "Object Oriented." Object Orientation is an abstract concept in itself that allows us to more easily abstract real world items into virtual objects and to manipulate them in a virtual world.
That's all. It is occasionally a very useful tool to have in one's bag of tricks. Sometimes it really doesn't apply at all and trying to force a fit just makes things labored and crude.
Trying to turn the entire universe of thought and logic into formal objects ( such as the number 1, which is most definately *not* an object), is putting the dogma before the cart, which then drags the poor cart anywhere the dogma wants it to go.
"Aspect" Orientation simply feels like a sect trying to break off from the Mother Church to me. This is not to say it may not be very useful, but that usefulness is needed because of doctrine in the first place.
Some things are objects. Some things are just operations or functions that have to be tortured beyond recognition if they're to be objectified. The less "pure" an OOP language the more *useful* I tend to find it, because it allows me to choose my methodology based on the problem.
Aren't there easier ways to add one and one and get two?
KFG
Hidden Horror Show (Score:4, Insightful)
Re:So, what is this? (Score:2, Insightful)
Re:Yet another reason to switch to Lisp (Score:5, Insightful)
(5 256 "Item" "Description") represents your base data type.
Programmer A:
"I don't need that first number..."
(256 "Item" "Description")
Programmer B (who get's A's data):
"What happened to that number?"
(256 "Item" "Description" 5)
Programmer C (who get's B's data):
"Strings? We don't need no stinking strings, we can look those up in a table! I can make that table global! Sweet!"
(256 1 20 5)
Person hired 2 years later to fix a bug:
"What the f*ck?!?"
It seems to me that Scheme and Lisp over-extended themselves, and are just too powerful/flexible for their own good, and that some "rules" should be in place...
And as the previous poster said...
((((()()))))
Lisp will make you hate parenthesis.
C
Re:So, what is this? (Score:2, Insightful)
I can see what you mean, but I do see this as different from operator overloading. Aspect weaving does not change the semantic definition of a language's mathematical operators. Depending on your AOP use, too, AOP advice may not have full access to the whole of the program to abuse it. I have seen some interceptor implementations that only let the advice have access to the context of the method call. Yes, this could mean that you could write advice that scrambles the parameters before a function call, leading to unsuspected results in the function call, and I would definitely call that abusive.
Honestly, though, that's the breaks. Being able to pass pointers into a function gives the author of a function the opportunity to wreck whatever's on the end of said pointers, and that allows for abuse, but I consider it worthwhile to do. There are great ways to abuse everything.
A dinosaur writes: (Score:4, Insightful)
P.S. I don't dress fashionably either, prefering to save valuable beer money.
Some thoughts from somebody who's using the tech (Score:3, Insightful)
In short, used judiciously, this is a very, very handy tool. Used indiscriminately, this is an utter fscking nightmare. And anybody who lets the project's junior-level coders work with this should be taken out back and shot. Repeatedly.
Debugging AOP? (Score:2, Insightful)
Aspect-oriented programming has been talked about for a while now, but it still isn't nearly ready for prime time. The obvious issues are that it will introduce bugs and that it will be at the same time very hard to debug.
The first goes without saying: every new technique can be considered a collection of novel ways that things can go wrong. Insofar as AOP is powerful, it will create whole new classes of bugs.
Things like AspectJ make things worse, though, because they are pre-processors. So debugging is going to involve tracing into machine-generated code. This does not need to be a nightmare, but somehow it almost always is.
There is also the issue of debugging your aspect specifications themselves, alluded to briefly in the article with the point about infinite recursion. I'm sure there are many other subtle and interesting bugs that AOP can introduce, and I'm very grateful to all the eager souls who are going to find and fix them over the next few years.
I think AOP solves a legitimate problem. I'm not by any means sure it's the best solution. In a few more years, when tools and techinques have matured a little, it may prove to be a valuable technique.
--Tom
Re:Yet another reason to switch to Lisp (Score:3, Insightful)
What I got from the review is simply further confirmation of Paul Graham's [paulgraham.com] hypothesis that more modern programming languages are asymptotically approaching the capabilities Lisp has had for decades.
The whole "join points / pointcuts" thing seems to me like a watered-down version of Scheme's (and other Lisps) dynamic-wind and call/cc.
(And didn't the B-type Golgafrinchans end up populating some utterly insignificant little blue-green planet orbiting a small unregarded yellow sun far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the Galaxy?
Re:I prefer reading... (Score:2, Insightful)
It has a chapter on naming things, and it has a lot of good guidelines for picking names. It strongly recommends settling on and using some standard, project-wide naming convention.
There is a a section describing the Hungarian naming convention. That section includes a frank discussion of it's drawbacks and caveats. A quote from that section:
Most critics of Hungarian - like the author of the CodingStyle document, apparently - don't understand it. You actually are closest to the money with point #2. I don't know where you got your other points from; your point #1 is specifically listed as something not to do.
You're supposed to use the variable names to indicate abstract types, not programming language types. If you're merely using a prefixes to indicate programming-language types (i.e., int iQuantity, char chInput, etc.) then you're doing it wrong.
You should actually read - rather than skim - Code Complete. It's teriffic book, no matter what your favorite OS is.
I'm sorry if this post seems a little grumpy, but reading Code Complete was a revelation to me (Aha, I'm not crazy, these other people around me are doing it all wrong! No wonder this disorganized mess doesn't work!) and it's still one of my favorites.
Re:So, what is this? (Score:3, Insightful)
Only dumb programmers become any more confused by operator overloading than by other kinds of overloaded functions.
I don't want to reduce the effectiveness of the smart ones by sheparding the stupid.
Re:disgusting (Score:3, Insightful)
Actually, this is precisely what AOP seeks to do. By gather all the logging or DB transaction logic into one place and giving rules to the compiler for determining when/where to insert that code, you achieve a very clean separation of concerns.
The business logic writer doesn't have to know about logging or transations, trusting that the aspect writer it correctly specified. However, if the business logic writer comes upon a special case, that could be handled outside the general Aspect covering that.
Attempting to apply Aspects to Aspects can get a bit dangerous. But then so can recursion, reflection or any other powerful tool.
I think AspectJ is an interesting technology that you ought to check out before sneering at. Certainly it does have problems - my biggest problems with AspectJ spring from it not being tightly integrated with the language. When I used it, there were issues with debugging, building large projects and with non-hacker acceptance. With any luck, these have been dealt with.
Re:Yet another reason to switch to Lisp (Score:3, Insightful)
Programmer 1:
struct Part {
int number;
string name;
string description;
int count;
};
Programmer 2:
Oh, how inefficient; let's just replace that
with integers and put the strings into a
"resource table" somewhere.
typedef int Part[4];
In fact, by using atoms rather than strings,
the Lisp programmer can achieve the efficiency
of C++ Program 2 while essentially preserving
the appearance of Program 1.
Note that the correct way of defining the
data structure would be with DEFSTRUCT or
as a CLOS object.
As for the parentheses, people who sit in
glass houses shouldn't throw stones: C/C++
syntax has numerous flaws. Is syntax like this
really better?
a[((unsigned)*(short*)b)]
What about expressions like "a = b << c + d";
do you really know how the precedences work out?
Lisp syntax, with the right editor, is easy
to input and easy to read. And unlike C/C++
syntax, it doesn't have any precedence issues
and it is extensible.
Re:So, what is this? (Score:2, Insightful)
And as a (bitter?) Lisp programmer, I'm suspicious of a language that isn't flexible enough to provide an easy way to integrate the pattern into the language without having to use some silly preprocessor or (god forbid) modify the compiler. =)
Re:Yet another reason to switch to Lisp (Score:3, Insightful)
How about XML?
Besides, every language has barackets. Just in Lisp all bracket are unified to be as (). Other languages use various forms of brackets: (), {}, [], ";", "new-line". Python use even space identation instead of brackets (the only thing I hate in Python!).
When the code is the data, unified brackets are much better for verification purposes. That's why XML also has unified brackets (just badly designed, IMHO).