Hacker News Reader

Comment by tdees40 | Hacker News Reader

Matlab, C++, C# and Java rule the roost in the finance world. Anything else is treated with intense suspicion by finance companies. (I was once at a very large financial company that wouldn't approve Python for use internally at all because it was open-source. Let that sink in. We used it anyway of course.)

And yes, R and Python are making real inroads in quant finance, but they still have a small market share. Most of the guys writing code either want MS Office integration (sadly all traders love Excel), raw speed (C/C++/Java), or easy prototyping (Matlab). People don't know Haskell, audit departments don't know Haskell, and Haskell isn't as fast as C++, so this is an uphill climb, but I wish them the best.

If you want to know the state of the art in quant finance, go stare at the horrible over-engineered debacle that is QuantLib and see what kind of programmers we have working in this area.

View on HN

The word on the street in the Haskell community is that what you say is definitely true in many places, but Haskell makes inroads by being pretty fast if not C fast, grabbing Excel interaction [1], and building banking-related DSLs [2]. The typical story is that the Haskell shop builds advanced tools atop Excel, analysts get excited and want more, then the Haskell shop teaches them just enough Haskell to run a pricing DSL. Static types make it so that relatively untrained programmers can still manipulate the DSL adroitly.

All that to say not that Haskell is going to beat Java/C++ in any visible time frame but instead to compare its use favorably with something like Python.

[1] See Paradise, Credit Suisse's Excel interop library (http://www.icfpconference.org/icfp2008/accepted/37.html)

[2] http://research.microsoft.com/en-us/um/people/simonpj/Papers...

I thought most of the Haskell uptake in finance was localized to the UK? This might have more to do with the interests of the high end talent there than a more global phenomena.

Could be. I'm not in finance personally, just rattling the grapvine. That said, the theory isn't bad: Lennart Augustsson, Don Stewart, and Neil Mitchell are all in the UK I believe.

I think the story still holds though: financial analysts are provided an upgrade path from Excel to Excel+Haskell backend, to Haskell embedded DSLs. The same sort of game might be happening with S&P in Boston.

Back in the 90s, Objective C (used for iPhones today) and other Smalltalks were big in Manhattan's financial scene. Scala is also being pushed in finance today by some boutique firms in Europe. And then there is of course Common Lisp...

This isn't that strange or unusual at all, the languages just sort of appear and get some local mass going, but nothing catches on globally.

> 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

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.

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.

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.

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

I would assume they don't want to use open source software because of the security headache of having to vet and verify all dependencies.

I would assume they don't want to use closed source software because of the security headache of having no way to vet and verify all dependencies.

Haskell is already heavily used in finance, and they chose to go this route because all the feedback they were getting from financial firms wanting to use haskell. Your little bubble doesn't generalize to the whole world.

If by "heavily" you mean there are a few notable (and exciting!) projects out there, then sure. But what percentage of working quants code in Haskell ever? Probably <5%.

What's 5% of say $100B? Nothing to sneeze at, I'd say.

I don't see what that has to do with anything. You made a bizarre assumption that the financial world is hard for haskell to break into, when both history and the current behavior of financial firms says otherwise.

Reply on news.ycombinator.com