Wednesday, December 28, 2005 

On Going Extralinguistic

In a comment about my post on AOP in C#, a reader asked my opinion on Aspect C++. To make a long story short: Aspect C++, and similar languages like Aspect Java, are quite interesting from the research point of view, but I probably won't use them in real projects. I could, however, use an AOP library like the one discussed in my post above.
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.
Comments:
Ciao
Ci consiglieresti qualche buona risorsa sull AOP in rete?
 
Un altro problema che queste soluzioni comportano è di leggibilità del codice: se il codice deve essre consegnato al cliente che vuole operarci in futuro, o anche solo ad un collega che non conosce la tecnica utilizzata, già conviene pensarci due volte...

Fabio
 
L'idea del linguaggio a due livelli mi ha sempre affascinato da quando ho letto quell'articolo. Ma devo dire che i vari AspectJ et simila non mi convincevano granchè. L'idea dell'interception è di sicuro più evoluta, ma mi chiedo se avremo mai quelle funzionalità che permettono l'interception in C++! Ma credi davvero che L'aop sia una rivoluzione come si dice in giro? non mi sembra abbia portato una svolta così come il passaggio dal paradigma funzionale a quello OO! Che ne pensi?
 
Fulvio: sul supporto in C++ non ci conterei molto, purtroppo. Tempo fa pensavo a quanto sarebbe utile in C++ un particolare modello di reflection, ovvero la reflection compile-time, su cui costruire quella run-time come libreria, potenziando allo stesso tempo le possibilita' della metaprogrammazione. Mi tengo l'idea nel cassetto, poi scopro che Vandervoorde ha fatto una proposta analoga al comitato di standardizzazione, senza successo. Per qualche ragione c'e' la diffusa opinione che la reflection debba essere costruita sopra il RTTI, lasciando ampia liberta' a chi implementa i compilatori, ed e' una strada a mio avviso fallimentare, che unita ai lunghi cicli di lavoro ANSI/ISO sta lasciando il C++ molto indietro sotto questo aspetto. Di method interception ancora non ne ha parlato nessuno in sede di standardizzazione...
Sull'AOP, il discorso sarebbe lungo ed un po' impopolare :-). Per sommi capi:
- gli esempi di AOP che si vedono in giro sono troppo infrastrutturali, e pochi programmatori sono cosi' interessati a questi "aspetti" :-). Mancano chiari esempi di utilita' a livello applicativo.
- l'OOP ci ha messo parecchio, dal Simula67 in avanti, a raggiungere una ragionevole diffusione. L'AOP non ci mettera' molto meno :-).
- l'OOP, nel bene e nel male, ha avuto la sua reale diffusione "di massa" grazie al C++, e quindi grazie anche alla precedente egemonia del C, anche se questo da' fastidio a molti. Dietro questo c'e' un discorso molto complesso, incluso il fatto che il C++ permette[va], di nuovo nel bene e nel male, di transitare dal C sapendo ben poco di OOP e imparando (anche male) sul campo. Ad oggi l'AOP richiede davvero di capire cosa si sta facendo, e questo e' sempre meno popolare :-) tra i programmatori.
Non vado oltre, magari un giorno scrivero' qualcosa di piu' serio / completo sull'argomento.
 
Post a Comment

<< Home