It's hard to assert whether some lib is over-engineered by doing code statistics without making analysis on what the lib is used for.If you take a look at the CGAL lib, a good C++ lib for Computational Geometry, it may appear to be even more engineered. But the problem it solves is already complicated (3D geometry) and it is very important while difficult to utilise the concepts, patterns whilst maintaining run-time performance at the same time.Many libs are simple, blackbox-like and independent because they solve independent problems -- however for more complex or flexible problems you have to adopt those large, self-contained lib systems that often bear its 'internal logic or philosophy' and you have to learn it (not easy).I would assess the engineering quality of such libs from a practical point, which is how flexible you can use the concepts/models provided in the lib to solve problems I am encountered. I personally do not give much credit to classes and member functions having lengthy names (even like a sentence) -- which is often an indication of them being too specialised or trying to do too much in one go.If a lib can let the user (me) writing some code that reads like a natural sentence (or maths expression) with punctuations (., ->, <, > and = etc) as word/phrase separators, it is from my point of view a very well engineered lib that is easy to understand and use. Such code is not only easy to maintain without much need for comments but also easy to expand like when we make natural sentences after learning new words.

QuoteOriginally posted by: i386It's hard to assert whether some lib is over-engineered by doing code statistics without making analysis on what the lib is used for.Many libs are simple, blackbox-like and independent because they solve independent problems -- however for more complex or flexible problems you have to adopt those large, self-contained lib systems that often bear its 'internal logic or philosophy' and you have to learn it (not easy).I would assess the engineering quality of such libs from a practical point, which is how flexible you can use the concepts/models provided in the lib to solve problems I am encountered. I personally do not give much credit to classes and member functions having lengthy names (even like a sentence) -- which is often an indication of them being too specialised or trying to do too much in one go.offcourse code statistics is not the only way to know if a library is simple to use or not, but metrics like "Afferent Coupling", "Efferent Coupling",LCOM,LCOMHS,"inheritance depth",Level,abstractness can give an idea if the library is low coupled, with high cohesion and if easily plugable or not.the previous metrics are focused in design and other metrics can be focused in implementation like functions having lengthy names and such metric can't give any indicator of design.and you are right for complex or flexible problems we have to adopt large, self-contained lib systems, but thoses libs must be well designed and low coupled, with high cohesion to avoid a complex design and implementation and some design metrics can help to detect high coupling and low cohesion.

QuoteOriginally posted by: lballabioQuoteOriginally posted by: katastrofaDo any commercial enterprises use QuantLib in production?Yes. But I'm not sure that I can make any disclosure if they don't.Hmm. That contradicts what I've heard from people, but you should know better.QuoteQuoteI've been following the QuantLib mailling list for a while and some email exchanges left me with certain doubts about the quality of their development process.Such as? I'm all for constructive criticism...Luigihttp://sourceforge.net/mailarchive/forum.php?thread_name=1251822758.10014.2.camel%40ITSUP001&forum_name=quantlib-devYou simply cannot such a basic function on a whim, without discussing the impact it will have on existing user code.

I don't think you can say something is over-engineered without looking at the problem it is solving, and/or comparing it to other approaches.If you look at QL compared to in-house analytics libraries you will find their complexity is vastly higher by whatever metric you choose.Firstly because QL does not do as much of the fine detail a fully implemented system must cope with, varying from ability to deal bad data that's leaked in, to hooks that allow it to work with disparate systems....and those are the good reasons. Most inhouse s/w has grown organically, and some is as "organic" as a jungle, and I know of several that are literally decades old. But I cannot honestly claim the deep personal knowledge of 50 banks analytics that would allow be to be an authority, but ironically as a HH I've learned what people at various levels in many banks think of their libraries, and I don't think I'm betraying any confidences when I say that most people think their analytics libraries suck bit time, when considered as s/w products.Some would love to move to QL, partly because it is "clean", but there is a good % of people who would like QL simply because they believe that their current libraries have become a barrier to progress.But to move any sizable business to QL would be a huge task, thus my perception is that it is widespread, but only on a tactical level.Over time I believe that unless a much better open source library suddenly appears, that a good chunk of the future is QL, but this will not be a sudden jump.

"Tell users that a routine needs to know the number of businessdays"That's often not enough, I need to be able to generate a complete schedule of fixing and payment dates, including such things of whether the coupon is paid at end of month or every N days (adjusted for holidays), etc. I need to be able to handle different daycount conventions. You need a stable date library which deals with this issues.

QuoteThat's often not enough, I need to be able to generate a complete schedule of fixing and payment dates, including such things of whether the coupon is paid at end of month or every N days (adjusted for holidays), etc. I need to be able to handle different daycount conventions. You need a stable date library which deals with this issues. That's a matter of creating a wrapper date class with methods for the day count conventions and yearly fraction, date rolling etc. And a schedule can be modelled as a NX4 matrix of cash flows, settlement, fixing dates etc. Andrea Germani in his new book and myself have done it in C# as well as the Excel integration.edit: boost has extensive support for dates as well.

Yes, that's the sort of thing I had in mind. It is some simplified version of the schedule, I understand?

QuoteOriginally posted by: outrunGood idea, and perhaps not introduce a specfic storage layout, but itterators instead..Good tip. Then you can separate policy from implementation and you are not locked in to one specific storage. I discuss it a bit at the end of sample chapter But we are now talking about *interfaces*, not object connection architectures.

QuoteOriginally posted by: katastrofahttp://sourceforge.net/mailarchive/forum.php?thread_name=1251822758.10014.2.camel%40ITSUP001&forum_name=quantlib-devYou simply cannot such a basic function on a whim, without discussing the impact it will have on existing user code.<sigh>. And now I'm at a loss as to how to phrase this without seeming defensive. I guess I'll just go ahead.Look at the whole story. Not surprisingly, it started with my mistake---I was fooled into thinking that the change was a bug fix for a corner case (in which case the impact on existing user code would be to make it work right) so I applied it. All of twenty minutes later, the original developer explained that it was a change of semantics instead, at which point I reverted the change. So I'd say that the process worked, since it promptly fixed my mistake...Luigi

Yes, QuantLib is over-engineered. An open-source finance library should be written in C, in the style of well-established numerical routines (such as those found in Numerical Recipes in C). The C implementation can then easily be augmented with bindings to higher level languages such as C++, Python, etc, using SWIG.

Ok I take that back. Perhaps the inner workings of the library SHOULD be written in C++, though a C interface is still useful for properly bind with other languages. My main complaint against QuantLib is not that it's written in C++, but rather that it's over-burdened with certain design patterns. With the QuantLib source code, more time is spent thinking about C++ design patterns than thinking about the actual problem at hand (quant finance). In contrast, the in-house libraries that I've seen (and built) are much "friendlier" than QuantLib due their deliberate simplicity. An additional issue with some of those design patterns is that they have negative implications for performance and for portability to newer hardware platforms such as GPUs.