You're talking about a "piece of software", NOT a programming language. BTW, a thing used by many is not necessarily what is required to make money.
"Which language to use (Novice Programmer)?"
Python
nono
Which language to use (Novice Programmer)
- Thread starter H2O
- Start date
"Which language to use (Novice Programmer)?"
Python
nono
Ever heard of Excel VBA? Sure, it's not big and it's not cleaver but it does the job.
I work on a trading floor (250+ bond/swap/Cred Derivs), I'm looking around now . . . yup, most guys have a spreaddy open.
Yeah, but that's not what you said. You talked about Excel - not VBA, didn't even mention it.
PS: be more careful with your spreaddies or you'll get your ass handed to you.
Quote from nononsense:
Yeah, but that's not what you said. You talked about Excel - not VBA, didn't even mention it.
PS: be more careful with your spreaddies or you'll get your ass handed to you.
To be fair, anyone who says they "use Excel" professionally in a trading/modelling environment will at least also use VBA, if not their institution's internal pricing library, functions, integration to static data database etc.
Then again, in large institutions, it would primarily be the desktop dev specialist from the IT department who'd keep everything working, rather than the trader.
Not using VBA if you use Excel for anything complex, would be very unusual.
Spot on.
My observation would be that, at the end of the day, IB's make the money in commoditised financial products (high volume, low margin, stuff, spot fx, govvie bonds etc). Systems are big, written in a "proper" language, straight throug processing for risk & settlements.
Or, they make money out of exotic, illiquid products (the weird end of credit derivs, local currency bonds, structured products, whatever). More often than not, these pricing/risk models are Excel/VBA based.
I'd agree. The margins on commoditised instruments are very tight now. The institutions make their money by outsourcing as many component pieces of their transaction flow as possible to cheap suppliers; probably located in 3rd world economies and hiring less traders/brokers/dealers to handle much higher volumes using desktop automation and smart dealing platforms. None of this requires significant proprietary risk per se; it is usually agency or simple intermediation.
Exotic instruments commonly are low volume; the main chunk of the p&l for OTC structures is derived from the 300bp spread that the principal finance department plunder before repackaging the risky remains for their clients to swallow. Given the complexity of pricing models required, most of the number crunching is done via much more lower level code that Excel/VBA offers. Excel and VBA would probably take a month to do what a farm of servers can model in 24 hours using proprietary technologies that banks spend millions on.
I am no programmer and the following is just an opinion about the easiest way …
Since you already are using excel for your automation, why don¢t you try to put your computational intensive algorithms inside a dll accessible from excel? This way you can overcome some of the serious shortcomings of excel (speed).
Suppose for example that you want to perform some tasks that VBA is unable to do efficiently.
Use a basic-like language and construct a dll with the computational intensive tasks. Freebasic http://www.freebasic.net/ can do that easily and you don¢t have to learn a new language as it has almost the same syntax as VBA.
dll fb code
'' fb side, compile as: fbc -dll mydll.bas
function myfunc alias "MyFunc" (byval arg1 as short) as short export
function = arg1 * 2
end function
VBA code that access the function inside the dll
'' vb side
declare function myfunc alias "MyFunc@4" (byval arg1 as integer) as integer
http://www.freebasic.net/forum/viewtopic.php?p=10234#10234
After spending a couple of hours you can decide if the improvement is satisfactory enough for your needs. If you need something trickier for building your application then you can learn one of the languages that the others have suggested.
Best Regards
If you can handle all this like building dll's, why still bother with Excel at all? Excel is a terrific tool, burt once you start to but into its limitations, it's time to look elsewhere.
Now, talking programming language for a novice, that's all together another question. Look at Python. Even M$ is moving that way.
A lot more time than that .......
What are people thinking ? A spreadsheet is just that - a spreadsheet. Many people try to do things that are wholly inappropriate in spreadsheets .... but you dont see very much of this mistaken line of thinking as the dollar penalty for being wrong gets large ....... although surprisingly I have seen it ....