Comment Re:Hopefully (Score 2, Interesting) 64
I've worked with traders on an interest rate derivatives desk for the past 7 years, basically using Excel, VBA, and C/C++ DLLs coupled to Tibco, Infinity as well as other custom software packages.
I submitted the article, and believe me, it will be a hard task to ween traders off of Excel - if even possible. I plan on rolling out parallel versions of the software I am producing - and we'll see which "version" the traders like better. I believe I will be able to flex and bend to the trader's whims more adeptly with QT/QSA, but we'll see. Excel will not be abandoned by any means, but if it is used to a lesser extent, than this will be making some headway.
Often, we just can't do things in Excel that we would like, with the control and protection we desire. Likewise, we find that traders often find "hard-coded" GUIs, without any scripting language or ability to customize the appearance to be lacking in flexibility as well.
I've written Excel DLL's for a long time, and believe me, I'm no fan of Microsoft's underlying API for exporting VBA variables / types back and forth to C / C++ DLL land.
Do you think APIs such as SafeArrayAccessData(...) or structures such as SAFEARRAYS and VARIANTs are elegant? Ever try passing nested structs that contain arrays of nested structs of unsigned numbers or BSTRings back and forth between C and VBA? I think the Microsoft APIs for doing this and the Microsoft documentation is crap. IMHO, the QT documentation looks clearer.
Additionally, I've been extremely impressed with QT as a GUI toolkit -unlike MFC/Win32 (or the complexity of COM). As far as support, we are planning on buying quite a few developer licenses / support from Troll tech. The price is not an issue and we like the license terms.
As far as "Things like compliance, due diligence, split second transaction accountability,...etc", you would be surprised how much traders mix in their own models/ calculations with programmer-built tools - With Excel, it's a real problem keeping software under control. I can't see how it could be worse with QT. Should be interesting....
Cheers,
Dave Linenberg (OopChugALug)
I submitted the article, and believe me, it will be a hard task to ween traders off of Excel - if even possible. I plan on rolling out parallel versions of the software I am producing - and we'll see which "version" the traders like better. I believe I will be able to flex and bend to the trader's whims more adeptly with QT/QSA, but we'll see. Excel will not be abandoned by any means, but if it is used to a lesser extent, than this will be making some headway.
Often, we just can't do things in Excel that we would like, with the control and protection we desire. Likewise, we find that traders often find "hard-coded" GUIs, without any scripting language or ability to customize the appearance to be lacking in flexibility as well.
I've written Excel DLL's for a long time, and believe me, I'm no fan of Microsoft's underlying API for exporting VBA variables / types back and forth to C / C++ DLL land.
Do you think APIs such as SafeArrayAccessData(...) or structures such as SAFEARRAYS and VARIANTs are elegant? Ever try passing nested structs that contain arrays of nested structs of unsigned numbers or BSTRings back and forth between C and VBA? I think the Microsoft APIs for doing this and the Microsoft documentation is crap. IMHO, the QT documentation looks clearer.
Additionally, I've been extremely impressed with QT as a GUI toolkit -unlike MFC/Win32 (or the complexity of COM). As far as support, we are planning on buying quite a few developer licenses / support from Troll tech. The price is not an issue and we like the license terms.
As far as "Things like compliance, due diligence, split second transaction accountability,...etc", you would be surprised how much traders mix in their own models/ calculations with programmer-built tools - With Excel, it's a real problem keeping software under control. I can't see how it could be worse with QT. Should be interesting....
Cheers,
Dave Linenberg (OopChugALug)
