It's just not worth migrating historic artifacts over from launchpad. > Yes, why bother porting jquantlib over to github when we can just start over. If you don't like the idea of the wrapper, JQuantLIb is there and there are lots of things to be done. It's unmaintainable if there's not a team working on it and if there's no money keeping it alive.įor these reasons, the wrapper is the more sensible thing.
#Launchpadworks easy writer code
JQuantLIb has more than 1,000 classes containing convoluted code and complex math. When I stopped working on it, the development stalled. Historically, I was responsible for ~50% of the code you see in JQuantLib. If SQuantLib (in Scala) takes off from this brief conversation, it would be a death sentence to JQuantLib, since Java applications would be able to interface with SQuantLib easily.
There are technical aspects that would take me 100 lines to describe them all but, in a nutshell, Scala is a much powerful language and far more capable and suitable to the job of wrapping QuantLib. I thing the correct approach is a wrapper written in Scala, so that QuantLib guys focus on the quant stuff whilst others focus on wrappers to other languages. But Scala was very incipient 7-8 years ago and I opted for going ahead with an implementation in Java. To be honest and very realistic about JQuantLib, it would be much more beneficial if we had invested time and effort writing a wrapper to QuantLib/C++ in Scala. Regarding Scala: Yes, I'm using only Scala at the moment. I would like to see JQuantLib active again with more people supporting it. Good to hear that in future you will be able to help.
0 kommentar(er)
