So, a couple of observations... FWIW...
DD Thanks, I for one found them constructive. In general, does the software industry carry on as usual?
At a high level, what strikes me as odd is that the library mixes up the 'what' of financial engineering with the 'how' at the very deepest level. There is way too much run time logic based into the basic class structure, much more than is desirable. Even 15 years ago, that would have seemed like a bad idea to most engineers working in large T1 IBs. BTW, there also too much business logic baked into the template structure, but that's tangentially off topic. In a modern library, with various language bindings, various distributed computing approaches, I would expect a lot more layering to be more natural.
DD Some developers in general want to have a solution ASAP while not fully understanding the problem or the consequences of their design decisions (or lack thereof). Most developers are from the OOP era (everything is an object). They missed on the 60s/70s system design. And hey might miss the FP boat if they
are not careful.
To be specific, I think was a very bad idea to bake in the observer pattern so pervasively across the library. How could that ever be a good idea. There is a place for push systems or dependency graph based systems for sure, but more often than not this is a distraction and actually quite undesirable. There is a huge overhead to engineer almost anything in client applications due to this. It would be much more natural to have client application direct the dependencies and then build a push framework on top as opposed to forcing everybody to mess around with handles. The amusing thing is that the lazy object approach seems to be aimed at partially undoing the potential run time overhead caused by excessive use of observer pattern updates...
DD Observer pattern is a HORROR story. I could write a book just why it is wrong. You are correct! Signals and delegates is the correct approach.
Follow on: GOF pattern are outdated BIG TIME (but Ioved them in CAD/CAM).
I also notice excessive, almost wild, usage of shared_ptr. This is used at a significantly too granular level. Not a good idea in my opinion. I have a definite preference for using heap memory management at a slightly more macro level and use containers to handle collections of smaller objects but not through shared_p tr. Again this causes a lot of overhead.
DD shared ptr is a blunt instrument, indeed, when used incorrectly. Even short-lived factory objects, which are scoped_ptr/unique_ptr.
Excessive usage of template programming techniques. Not my cup of tea. I may not be a sufficiently proficient C++ programmer, but in my opinion template are suitable for generic programming, not so much for financial engineering. It's debatable, but when I see how templates have been applied to introduce the various TermStructure classes, I don't actually think that this affords that much flexibility in an area where the library is lagging 10 years or so behind.
DD TMP is gold-plating/over-engineering. Michael Jackson (not the singer) said:
1. Don't optimise 2. DDon't optimise yet (and then for experts). TMP sounds hip.
As a project manager said: TMP is fine, but do it your own time. TMP destroys creativity and it ensures that the quant project will never get completed,
It's also weird to me that so much dynamics is built into the instruments. Pricers or pricing engine deserve to be more first class citizen.
DD In agree 100%. I think OOP is obsessed with objects, losing sight of the bigger picture.
I observed and begin to understand that a lot of people I talk to in interviews are in the business of ripping the library for all the goodness it has. On the other hand there appear to be several consulting groups out there who have learned to put up with the nonsensical overhead and just use the library as is.
DD What is 'ripping'?
I wonder if it would be worth starting to build a library based on QuantLib that focuses more on laying out a clean collection of objects and methods. Something lower level, that handles only a subset of functionality maybe.
DD I once bought a quaint old farmhouse. There was a choice between renovating it or starting from scratch. I made a choice.
QL is based on GOF/OOP and this is not the next gen paradigm. I am just the messenger. I would start again. Talk is cheap and you need a budget and 2-3 experienced team members.
I think some kind of top-down architectural design and bottom-up implementation keep 'em sharp..
// attachments on how I try to solve problems.
// Also a chapter on MC using delegates instead of that pernicious Observer. No inheriting a SDE from Observer