Friday, December 30, 2005
Some AOP resources
Vigj asked for some online resources on AOP, so here are a few links:
Theoretical stuff and a few examples of application: Software Design Area at Xerox PARC.
Aspect-Oriented Software Engineering SIG at Lancaster University. Several papers, mostly about persistence, but also some interesting stuff at requirements level.
Tutorial and Workshop on Aspect-Oriented Programming and Separation of Concerns at Lancaster University.
Aspect-Oriented Software Development: Conference Archives. Unfortunately most stuff is archived in the ACM Digital Library, which requires a subscription. Some papers are quite interesting, so I've included this link anyway.
Aspect-Oriented Software Engineering SIG at Lancaster University. Several papers, mostly about persistence, but also some interesting stuff at requirements level.
Tutorial and Workshop on Aspect-Oriented Programming and Separation of Concerns at Lancaster University.
Aspect-Oriented Software Development: Conference Archives. Unfortunately most stuff is archived in the ACM Digital Library, which requires a subscription. Some papers are quite interesting, so I've included this link anyway.
Wednesday, December 28, 2005
On Going Extralinguistic
The reason is pretty simple: Aspect C++ is a new language, based on C++. It has to be so, because C++ is (unfortunately) missing some core abstraction that we would need to move aspects into a library. Moving outside the mainstream language, however, has several disadvantages in the real world. In most cases, a language extension is built as either a standalone compiler or as a preprocessor over the standard language. Both have advantages and disadvantages for the language designer / implementer, but I won't go into that. They also have significant disadvantages for the language user, that is, for the rest of us.
If the extended language is implemented as a brand new compiler, the programmer:
- has to give up his familiar compiler (meaning: learning new options, new bugs, etc)
- may have to give up other tools (debugger, profiler, and so on), unless the new compiler is somewhat "compatible" with the old one at the binary level.
- may have serious troubles linking with third party libraries, unless again there is some compatibility at the binary level.
If the extended language is just a preprocessor, we don't have any of those problems. However:
- debugging is usually a mess, because we'll be seeing the post-processing code. There are kludges in the C family to fool the debugger, remap line numbers and so on, but this is basically a huge mess.
- other tools, like profilers, share the same problem.
- compile-time error messages can get very hard to read. Unless the preprocessor can catch all the errors not only in the extended portion of the language, but also on the standard portion, some error will be caught only on the post-processed file, and we'll have to reconstruct the corresponding code in the source code (with AOP, this is not necessarily easy).
- there is also the risk of someone changing the post-processed file instead of the original, but this is somewhat less important.
These are common concerns, unrelated to AOP. In fact, the most fascinating idea in template metaprogramming in C++ is that we don't need an extra-linguistic solution. Sure, we could do all that stuff (and more) with a preprocessor, even with a few PERL scripts in some cases. But template metaprogramming does not require to move outside the core language. Of course, recognizing template metaprogramming as an officially supported programming paradigm in C++ would be an important step. Today, diagnostic is weak to say the least, there is no debugging support at all (debugging at compile time is not exactly easy :-), and so on. But this could be improved, and in doing so, we would have a more powerful core language, upon which better libraries could be built.
Along the same line, my ideal "Aspect C++" would be a C++ with two core abstractions that are currently missing (reflection and method interception), upon which an AOP library could be built, and certainly much more.
This would be aligned with the concept of C++ as a 2-levels language. My Italian readers may want to read my C++, Java, C#: qualche considerazione for more on 2-level languages. It's interesting to see how C# is gradually evolving in a 2-level language, with .NET attributes and reflection as a cornerstone in this development.
Monday, December 26, 2005
Random readings
I particularly appreciated the sociotechnical perspective on the spam problem. Defining the concept of legitimate (a distinct concept from legal, and even from fair) communication, and then analyzing message, channel and address ownership under that framework, gives a break from the nerdy approach to spam fighting (Bayesian filters on steroids :-) and provides some useful insights on how technology should be considered as part of a larger socio-technical system.
The authors (possibly because of limited space) don't talk much about the bright side of unregulated email. They mention the idea that in the real world, we make a clear distinction between meeting someone new or someone familiar. They also mention the fact that email ignores this basic social distinction. They elaborate on the negative side of that, as the paper is focusing on spam. I can also see the positive side. The internet has always been a huge social experiment. Email, from the very beginning, created a parallel social hierarchy, where total strangers had an implicit right to write to any address they managed to get. In the beginning, this was a great equalizer. Existing social hierarchies were routinely short-circuited, largely for the good. This is no longer true, but we should not overreact. IP filtering, for instance, is a dumb countermeasure in a world where most home users get a dynamic IP, and then see their emails rejected for no good reason. Indeed, this is a nerdy countermeasure, ignoring the social impact of punishing the innocent, and unpredictably cutting the parallel hierarchy...
Saturday, December 24, 2005
Merry Christmas!
For those of you I've met in the past, for those of you I'll meet in the future, for those of you I'll never meet, my best wishes for a joyful life...
Friday, December 23, 2005
Been away for a while...
2005 is winding down, and in the last month I've been so busy I barely had time to post here. Since my last posting, I've been:
- teaching and consulting at a VoIP company. 64 bits machines came up again, while calculating (back of the envelope :-) the memory footprint of serving a few hundred thousand clients.
- teaching patterns at a NATO lab. I prototyped some new exercises, and overall the result was good. The problems where neither too easy nor too hard to solve, and engaged participants in interesting discussions. We also discussed an ongoing project, and once again 64 bits came up, this time while thinking about very large image processing.
- teaching software project management at a software house working on solid modeling, and then working with their management on defining which [new] techniques should be adopted as part of the next planned release.
- learning more about the insurance business.
- consulting at an insurance company on evolving a legacy system, a 6 millions lines COBOL monster :-) which is still their operational core, toward a web-enabled, service-based system.
- traveling a lot :-). I don't have a figure, but certainly more than a few thousands km. Airplanes help :-).
Looking forward, I'd say 2006 is going to be fun...
- teaching and consulting at a VoIP company. 64 bits machines came up again, while calculating (back of the envelope :-) the memory footprint of serving a few hundred thousand clients.
- teaching patterns at a NATO lab. I prototyped some new exercises, and overall the result was good. The problems where neither too easy nor too hard to solve, and engaged participants in interesting discussions. We also discussed an ongoing project, and once again 64 bits came up, this time while thinking about very large image processing.
- teaching software project management at a software house working on solid modeling, and then working with their management on defining which [new] techniques should be adopted as part of the next planned release.
- learning more about the insurance business.
- consulting at an insurance company on evolving a legacy system, a 6 millions lines COBOL monster :-) which is still their operational core, toward a web-enabled, service-based system.
- traveling a lot :-). I don't have a figure, but certainly more than a few thousands km. Airplanes help :-).
Looking forward, I'd say 2006 is going to be fun...
Sunday, December 11, 2005
AOP in C#
I'm somewhat in a hurry, so I'll have to get back to this later, but if you look at the example given, you'll see you need to go through a factory. This is necessary because you won't get back an instance of the type you request, but of synthesized subclass. That's at odd with source code generators, of course, but that would be another long story. Of course, it would be much nicer if we could override the global operator new in C#, but we can't. However, C# is evolving into an interesting language (leaving aside my distaste for garbage collection...) and we could end up with something interesting in the future. More on this another time...
Sunday, December 04, 2005
Patterns as a Language
Patterns are not meant to provide us with never-thought-before gems, but with pearls of wisdom. Even more important, patterns are about sharing that wisdom through our language: in fact, patterns makes us smarter by extending our vocabulary.
You'll never realize the full potential of patterns if you design and code by yourself. But if you spend a significant amount of time talking about design, like in joint design sessions, patterns deeply influence the way you talk, think, communicate.
When everyone involved is familiar with patterns, you can just say "we can use an abstract factory here, and create a chain of responsibility there", and by doing so, you'll communicate the problem as you perceive it, the surrounding forces, and a candidate solution. That's the true power of patterns. A pattern-savvy team is usually more productive, because people engage in higher-level conversations.
John Vlissides, one of the Four, recently left us for greener pastures. He did a great job, moving our collective understanding of software design a few, significant steps further. Thank you, John.
