4 ms·

> sadly all traders love Excel Why do you say 'sadly'? Excel is an incredible tool that other traders can work with, it is sufficiently expressive to run trad

by sheetjs 13y ago

> sadly all traders love Excel Why do you say 'sadly'? Excel is an incredible tool that other traders can work with, it is sufficiently expressive to run trades and backtests, and the connectors (e.g. Bloomberg) are better than the python equivalent

kasey_junk 13y ago
I don't have any problem with csv files, but models that are embedded in a mix of formula's, multiple workbooks connected over the network, & VBA are tons harder to translate to production level code than those written in other numerical systems.
tdees40 13y ago
The problem with Excel is a problem of state. It's great for viewing immutable information (although custom web apps aren't difficult for most basic tasks), but as soon as you get into running production processes in Excel things fall apart. A single stray keystroke populates a random cell, which blows up your calculations, and you can't figure out what you did. This has happened dozens of times in my career in finance, and I've found no reasonable solution to it.
nazka 13y ago
Because if you miss something - and traders are not known as being awesome coders - you end up with something like the London Whale. $2B of loss because a guy on his little spreadsheet missed something after thousands of copypasta... And it's not the only one. On an engineer pov with everything we invented (such as CI, or no single point of failure in databases) it is just purely unbelievable.
dredmorbius 13y ago
There's a long history of spreadsheet errors and literature on same going back a few decades now. In a business sim class in college a couple of decades back, I discovered that the Lotus spreadsheets (as I said: a couple of decades back) had a totalling error which double-counted individual row totals in the bottom line (everything was twice as profitable as the spreadsheet indicated). At an early gig, one of the senior developers instituted a practice of code walkthroughs on projects (only a subset of them). One of these involved, you guessed it, a spreadsheet (we used a number of other development tools for much of our work), in this case Excel. Again, numerous errors which substantively changed the outcome of the analysis. One of the walkthrough leader's observations was that you could replace all of the in-cell coding with a VBA macro making debugging far easier (all the code and data are separated and in one place each). The particular analyst whose project this was: he insisted to the very end that this "wasn't a program" and he "wasn't a programmer" and that the walkthrough didn't apply to his situation. Despite the errors found and corrections made. At the time (mid 1990s) the walkthrough lead turned up a paper from a researcher in Hawaii on the topic. I'm not certain it was Raymond Panko, but his 2008 paper (a revise of a 1998 work) discusses the matter in depth: http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm

by sheetjs 13y ago

kasey_junk 13y ago

I don't have any problem with csv files, but models that are embedded in a mix of formula's, multiple workbooks connected over the network, & VBA are tons harder to translate to production level code than those written in other numerical systems.

tdees40 13y ago

The problem with Excel is a problem of state. It's great for viewing immutable information (although custom web apps aren't difficult for most basic tasks), but as soon as you get into running production processes in Excel things fall apart. A single stray keystroke populates a random cell, which blows up your calculations, and you can't figure out what you did. This has happened dozens of times in my career in finance, and I've found no reasonable solution to it.

nazka 13y ago

Because if you miss something - and traders are not known as being awesome coders - you end up with something like the London Whale. $2B of loss because a guy on his little spreadsheet missed something after thousands of copypasta... And it's not the only one. On an engineer pov with everything we invented (such as CI, or no single point of failure in databases) it is just purely unbelievable.

dredmorbius 13y ago

There's a long history of spreadsheet errors and literature on same going back a few decades now. In a business sim class in college a couple of decades back, I discovered that the Lotus spreadsheets (as I said: a couple of decades back) had a totalling error which double-counted individual row totals in the bottom line (everything was twice as profitable as the spreadsheet indicated). At an early gig, one of the senior developers instituted a practice of code walkthroughs on projects (only a subset of them). One of these involved, you guessed it, a spreadsheet (we used a number of other development tools for much of our work), in this case Excel. Again, numerous errors which substantively changed the outcome of the analysis. One of the walkthrough leader's observations was that you could replace all of the in-cell coding with a VBA macro making debugging far easier (all the code and data are separated and in one place each). The particular analyst whose project this was: he insisted to the very end that this "wasn't a program" and he "wasn't a programmer" and that the walkthrough didn't apply to his situation. Despite the errors found and corrections made. At the time (mid 1990s) the walkthrough lead turned up a paper from a researcher in Hawaii on the topic. I'm not certain it was Raymond Panko, but his 2008 paper (a revise of a 1998 work) discusses the matter in depth: http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm