Growing up and moving into the finance industry? Excellent! Please fix the typo in the 'FP Haskell Center (TM) Overview' section:
"... The personal edition aslo includes Emacs support ..."
While I want to cheer on esoteric languages and functional programming, this seems like just more smart people wasting their brains on zero-sum detrimental finance games. At least for them, they'll probably make a lot of money.
Eh, could produce some more generally applicable improvements, though it depends on whether they share back any code or expertise to the community. Some stuff I don't much like has produced very useful ancillary advances (the U.S. military is probably the biggest example), though some tech+finance companies are kind of black holes that never publish code/data/anything, so depends.
That depends on the market, doesn't it? They didn't say they were explicitly building systems for Forex, right?
And who are you to tell people what they should "waste their brains on"? A lot of programmers I know in research labs/academia speak condescendingly towards really intelligent SV programmers who "waste their brains" on moving pixels around a screen in order to make people click more ads.
Fwiw, that line actually came from someone in the tech industry, though no doubt some academics also like it. The oft-paraphrased quote is from Jeff Hammberbache, an early Facebook employee, who at the time of the comment was at Cloudera: "The best minds of my generation are thinking about how to make people click ads. That sucks."
So far, no one seems to have come up with an economic system that's more effective in harnessing the collective skills of the human race to improve the world (on balance) for everyone than the one we have at the moment.
It has the regrettable feature that it strongly incentivizes some very smart people to spend their careers encouraging people to click on advertisements, and some other very smart people to spend their careers arranging for the profits from exploiting subtle equity mispricings to flow to one random set of rich people rather than another. But the net effect is pretty good, or more precisely less depressingly wretched than that of any other system found to date.
(And some of those very smart people get rich by encouraging ad-clicking or exploiting equity mispricings, and then use their money and/or freedom to do neat things from which everyone benefits. Is that such a bad way for things to work?)
I guess I have some doubt that the American economic system in particular is a local optimum. Something radically different carries risks, yes. But the American system is a bit of an extreme in its encouragement to do anything that makes a profit, even within the local space of variation of vaguely market-based mixed economies. In Denmark, we have a bit more "managed" economy, perhaps even "socialist" in a certain weak sense (there used to be more of a socialist ethos, alas). The country is a bit less focused on VC returns, big paydays, and "exits", and frowns a bit more on people doing mercenary nonsense for profit. You get paid to go to university, there is extensive arts funding, an industrial/scientific policy, etc., among other things that try to redirect energies elsewhere. And that historical "approximate equality for all, big profits for none, put your energy into something worthwhile" approach to an economy has really not been disastrous, quite the opposite.
I didn't actually mean the American system specifically. (I'm in the UK, for what it's worth.) My own preferences are quite leftish and I would prefer the UK to be more like Denmark than it is. But, still, the US seems to be quite effective in producing new technological things, and maybe that's partly the entrepreneurial mercenary culture as well as the mere fact of being a rich country.
Anyway, the "system" I had in mind was the (not necessarily well defined) global one of which the US, the UK and Denmark are all parts.
>But, still, the US seems to be quite effective in producing new technological things, and maybe that's partly the entrepreneurial mercenary culture as well as the mere fact of being a rich country.
Speaking as a born USAian, I honestly believe it's more that the USA can and does brain-drain the entire rest of the world. When you actually raise people in an environment of mercenary capitalism, what you mostly get is poor people. When you let social-democratic states across the world raise and educate people, let them fund their research or their early attempts at businesses, and then steal those people when they get successful enough to be an easy bet and put them in a ruthless entrepreneurial environment, then you get a seemingly high concentration of high-talent, high-productivity businesses.
It's kind of like how people outside Israel say we've become a high-tech powerhouse through the discipline of our military training, but actually the Israeli army is one of the world's worst bloated, effort-wasting bureaucracies for every soldier outside a tiny elite.
1. Fortunately we have taxation to turn highly profitable zero-sum professions into slightly less profitable positive-sum ones.
2. If doing stuff for the quantitative finance industry means more resources for building generally useful Haskell libraries, then everyone wins.
3. If you make a lot of money playing zero-sum detrimental finance games, then you can (a) retire and do more interesting or socially-useful things (like contributing to interesting software projects) and/or (b) give a pile of it away.
On 3b, I'll remark that although I don't work in the finance industry (I've spent most of my career doing R&D for small technology companies), my salary has never been very large by present-day Silicon Valley standards, and my charitable giving isn't especially heroic, I think it very likely that I've done more net good to the world by giving away some of what I earn than I ever have by doing my actual job. If I were to move into finance (which isn't impossible -- I'm a mathematician and quite a lot of mathematicians do that) then it would probably be a net gain in global utility even if everything I did could correctly be called zero-sum detrimental finance games.
Joe is a hedge fund manager. His job consists of arranging for one bunch of random rich people (his fund's clients) to get a little bit richer at the expense of another bunch of random rich people (other people trading in the same markets). For doing this, his clients pay him $10M/year.
The government takes $3M/year of this (note: all numbers in this comment are made-up nonsense), which it uses for building roads and paying schoolteachers and paying for some people's healthcare.
End result: Joe's clients, in exchange for Joe's skill at siphoning money out of the stock market (or wherever) to them, have in effect paid $7M to Joe and paid $3M to build roads, provide medical services to poor people, provide education to everyone, etc.
What controversial assumptions are necessary to make that end result (1) plausible and (2) positive-sum despite the net uselessness of Joe's work?
In some cases one can argue that the useful things done with tax revenue need to be offset against the reduced incentive to work created by the existence of taxes. Not in this case, I think. Joe's work is, to a very good approximation, completely valueless to society, and it does good overall only by being taxed. And if the prospect of being paid only $7M/year makes Joe quit hedgefundery in favour of some easier and less stressful but less well-paid profession, the chances are he'll do more good there. (More precisely: If the world's Joes collectively decide to do a bit less hedge fund management and a bit more engineering or something, that's probably all to the good.)
(It may sound as if I'm criticizing Joe. I'm not. He's not doing any harm to speak of, I think his earnings do a lot of good by being taxed, and of course he may be doing other useful things with some of that money.)
I would like to read details about the model -> production code that the IAP product uses.
I've been developing an interest in statistical modeling and moving those models to production code (and of course, quantitative finance is an "obvious" place where this happens). But I find, even in the statistical genomics world, that the default process still seems to be:
(1) specialized tools for data cleaning and initial crunching (maybe hadoop, maybe HPC clusters
(2) consumption of data from (1) in R or Stata/SAS for model generation
(3) only vague, research-y things where the model from (2) goes to production.
The vague part of (3) is probably just due to my simply not knowing what people are doing with the generated models in (2).
Specifically regarding quantitative finance, it would seem that trumpeting your implementation programming language would mainly be met with blank stares, Jane Street excepted . . .
Having built systems that try to do this in the past, I encourage you to question a few assumptions that many people have about the inefficiencies of this silo'd model.
(1) That quants want to program (or that the business should want them to) in something other than R, Matlap, NumPy, Julia, etc.
(2) That the hard part of moving a model into production is translating the model.
(3) That the model is the part of the system that will be the main driver of success.
I've found that quants do not follow software best practices. They do not produce production ready code and it isn't because they aren't using the right language. It's because they aren't production software developers (and I don't want them to be, I want them out there doing analysis). Further, I've never encountered a model that didn't over simplify operations/execution requirements. They do this so that they don't get bogged down in details when they haven't figured out the big picture yet, and that's a good thing.
What drives success is having a good set of quants who can communicate with production capable software engineers. At the end of the day, the hard part of a quants job is usually finding concepts. Once they are found translating them into something actionable is usually reasonably easy.
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.
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:
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.
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.
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%.
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.
IPython + Pandas[0] + (sklearn/cvxopt/etc.) are an amazing combination and as far as I can see gaining share. I would love to work in Haskell but I'm always scared the library support / interactivity won't be there. Pandas has 8600 commits at the time of writing, unassailable?
This stack gets a LOT of use in HFT. (Including us)
Honestly, the three things I'd most love to have are:
- more wrappers, support, documentation on PyMC -- a LOT could be done here and this could replace HUGE amounts of code in all sorts of place
- libraries/models on top of cvxopt
- more polished ipython notebook -> pdf or d3.js html -- I do this a fair amount for auto eod reports etc
And maybe a fourth...a good open source alternative to kx...preferably one that can accept .h5 files.
Haskell has been used to model financial contracts by a few firms with an eye towards type-level correctness guaranteed by the compiler (that you cannot get with "mundane" type systems found in C++ / C / Java / etc...) That, coupled with Haskell's speed, concurrency features, and other amazing features makes it an attractive platform.
Alpha Heavy Industries is a small(er) SV based firm using Haskell a lot.
You can have more mutable types/classes at run-time and more injections instead of the concrete ones defined at compiled time?
Also, can you give any concurrency examples in terms of concurrency features? Is it similar to Actor model in Scala? Or based more on concurrent data structures as in java.util.concurrent.*?
Take a look at [1] for details on the contract language they built. Instead of modeling things in a taxonomy, they build the logic of contracts up from primitives using a combinator library.
Concurrency in Haskell is a big thing. At the lowest level, purity means there's a lot of opportunity for parallelization. Atop that Haskell has a really great green threads system and new GHC has a very, very performant IO manager for running them. It's GC'd so you do have thread-local pauses and they're not as nice as Erlang's actor-local GC. Atop that you've got a nice channel system, the best implementation of Software Transactional Memory around, and neat new libraries like LVish for doing eventual consistency in a very reasonable fashion.
Thanks tel for the helpful example, I scanned through [1] briefly and will be attempting to grok the details later. But very interesting paper on using Haskell combinators as opposed to the ugly Java single-inheritance model to make up more and more complicated securities piecewise. Tbh, I'm quite envious of using functional languages and will use the examples to try to learn it (since I'm familiar with the domain area of financial contracts only in imperative lang though).
I also like to learn concurrency in Haskell and don't know a thing about it (currently, I'm trying to go over Clojure concurrency features). So what you have mentioned regarding the LVish framework and Erlang's actor-local GC, green threading will give me a good starting point to poke around. Thanks again for your note!
How does one get into the financial industry with software engineering skills with some day trading and financial knowledge (Econ major here). What would be a good step to break into this side of finance? It seems everything is more strict.
If you hope to make money from trading (beyond the quite respectable gains you can get just from buying index funds or whatever), you basically have two ways to do it. (1) Make better predictions (or better adjustments for risk, or better hedging of one asset against another, etc.; these are all closely related) than others. (2) Buy and sell without any attempt at predicting the future; be willing to take the other side of any trade anyone wants to make, in return for which you get to buy a little low and sell a little high.
For #1 you need quantitative finance. #2 is the activity known as "market making" and HFT is what you get when you automate it and then let the people doing it compete. The algorithms in HFT are pretty simple-minded; the goal is to offer as thin a spread between buying and selling prices as you can while still making a profit, and to offer it faster (when someone comes looking to trade) than anyone else. The latter is genuinely useful when it's the difference between (say) 5 minutes and 5 seconds. Unfortunately the same incentives that make it worth while for high-frequency traders to offer sub-second response times then make it worth while for them to keep chasing faster and faster times, until the most important asset a HFT shop has is a bunch of computers positioned slightly closer to a big exchange than anyone else's.
There's not much of what people mostly mean by "quantitative finance" in a typical HFT system, I think.
I think quantitative finance is interesting, but for personal purposes I'd really only want to trade once a month or so, as opposed to multiple times a day. I'm not sure what kind of software libraries/languages are suited for that kind of approach, when everything seems tuned for HFT.
For that kind, you don't really need any specific software. You can do it in Ruby/Python/Haskell/Whatever. As long as you can communicate with an API (Yahoo Finance to download the data for example and one broker that allows you API access to issue orders) any language will do. You can run your software once a month or week, analyse the data and issue the orders. If you are keen, you can even use Google News/NLP/Sentiment Analysis in your model, again, in any languages you want.
Take a look at: quantstart.com He has some tutorials with Python to do so, and he is releasing a book (hopefully soon) that should give you a good overview of it all. Also, I recommend you read Options, Futures and Other Derivatives to understand how most of this financial instruments work. There is a lot of good information there.
Thank you - that is very good information. I have done some perl scripting using "Finance::Quote" and "Finance::QuoteHist" but I guess I have been looking for the next step up. Particularly historical financial statement information, like EPS and Sales data quarterly history. Historical fundamentals as a data feed. I don't know where to find that. I'll check quantstart and see what they offer.
53 comments
[ 2.3 ms ] story [ 110 ms ] threadThat depends on the market, doesn't it? They didn't say they were explicitly building systems for Forex, right?
And who are you to tell people what they should "waste their brains on"? A lot of programmers I know in research labs/academia speak condescendingly towards really intelligent SV programmers who "waste their brains" on moving pixels around a screen in order to make people click more ads.
It has the regrettable feature that it strongly incentivizes some very smart people to spend their careers encouraging people to click on advertisements, and some other very smart people to spend their careers arranging for the profits from exploiting subtle equity mispricings to flow to one random set of rich people rather than another. But the net effect is pretty good, or more precisely less depressingly wretched than that of any other system found to date.
(And some of those very smart people get rich by encouraging ad-clicking or exploiting equity mispricings, and then use their money and/or freedom to do neat things from which everyone benefits. Is that such a bad way for things to work?)
Anyway, the "system" I had in mind was the (not necessarily well defined) global one of which the US, the UK and Denmark are all parts.
Speaking as a born USAian, I honestly believe it's more that the USA can and does brain-drain the entire rest of the world. When you actually raise people in an environment of mercenary capitalism, what you mostly get is poor people. When you let social-democratic states across the world raise and educate people, let them fund their research or their early attempts at businesses, and then steal those people when they get successful enough to be an easy bet and put them in a ruthless entrepreneurial environment, then you get a seemingly high concentration of high-talent, high-productivity businesses.
It's kind of like how people outside Israel say we've become a high-tech powerhouse through the discipline of our military training, but actually the Israeli army is one of the world's worst bloated, effort-wasting bureaucracies for every soldier outside a tiny elite.
Except:
1. Fortunately we have taxation to turn highly profitable zero-sum professions into slightly less profitable positive-sum ones.
2. If doing stuff for the quantitative finance industry means more resources for building generally useful Haskell libraries, then everyone wins.
3. If you make a lot of money playing zero-sum detrimental finance games, then you can (a) retire and do more interesting or socially-useful things (like contributing to interesting software projects) and/or (b) give a pile of it away.
On 3b, I'll remark that although I don't work in the finance industry (I've spent most of my career doing R&D for small technology companies), my salary has never been very large by present-day Silicon Valley standards, and my charitable giving isn't especially heroic, I think it very likely that I've done more net good to the world by giving away some of what I earn than I ever have by doing my actual job. If I were to move into finance (which isn't impossible -- I'm a mathematician and quite a lot of mathematicians do that) then it would probably be a net gain in global utility even if everything I did could correctly be called zero-sum detrimental finance games.
Joe is a hedge fund manager. His job consists of arranging for one bunch of random rich people (his fund's clients) to get a little bit richer at the expense of another bunch of random rich people (other people trading in the same markets). For doing this, his clients pay him $10M/year.
The government takes $3M/year of this (note: all numbers in this comment are made-up nonsense), which it uses for building roads and paying schoolteachers and paying for some people's healthcare.
End result: Joe's clients, in exchange for Joe's skill at siphoning money out of the stock market (or wherever) to them, have in effect paid $7M to Joe and paid $3M to build roads, provide medical services to poor people, provide education to everyone, etc.
What controversial assumptions are necessary to make that end result (1) plausible and (2) positive-sum despite the net uselessness of Joe's work?
In some cases one can argue that the useful things done with tax revenue need to be offset against the reduced incentive to work created by the existence of taxes. Not in this case, I think. Joe's work is, to a very good approximation, completely valueless to society, and it does good overall only by being taxed. And if the prospect of being paid only $7M/year makes Joe quit hedgefundery in favour of some easier and less stressful but less well-paid profession, the chances are he'll do more good there. (More precisely: If the world's Joes collectively decide to do a bit less hedge fund management and a bit more engineering or something, that's probably all to the good.)
(It may sound as if I'm criticizing Joe. I'm not. He's not doing any harm to speak of, I think his earnings do a lot of good by being taxed, and of course he may be doing other useful things with some of that money.)
I've been developing an interest in statistical modeling and moving those models to production code (and of course, quantitative finance is an "obvious" place where this happens). But I find, even in the statistical genomics world, that the default process still seems to be:
The vague part of (3) is probably just due to my simply not knowing what people are doing with the generated models in (2).Specifically regarding quantitative finance, it would seem that trumpeting your implementation programming language would mainly be met with blank stares, Jane Street excepted . . .
(1) That quants want to program (or that the business should want them to) in something other than R, Matlap, NumPy, Julia, etc. (2) That the hard part of moving a model into production is translating the model. (3) That the model is the part of the system that will be the main driver of success.
Good Luck!
What drives success is having a good set of quants who can communicate with production capable software engineers. At the end of the day, the hard part of a quants job is usually finding concepts. Once they are found translating them into something actionable is usually reasonably easy.
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.
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
On an engineer pov with everything we invented (such as CI, or no single point of failure in databases) it is just purely unbelievable.
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
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 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.
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.
[0] http://pandas.pydata.org/
Honestly, the three things I'd most love to have are: - more wrappers, support, documentation on PyMC -- a LOT could be done here and this could replace HUGE amounts of code in all sorts of place - libraries/models on top of cvxopt - more polished ipython notebook -> pdf or d3.js html -- I do this a fair amount for auto eod reports etc
And maybe a fourth...a good open source alternative to kx...preferably one that can accept .h5 files.
http://continuum.io/
I can be reached at hugo@continuum.io if you want to chat about it
Alpha Heavy Industries is a small(er) SV based firm using Haskell a lot.
Can you give a more specific example? Are you saying that instead of in Java/C++ where you have:
GenericSecurity > GenericOption > EuropeanOption, BarrierOption, AmericanOption
You can have more mutable types/classes at run-time and more injections instead of the concrete ones defined at compiled time?
Also, can you give any concurrency examples in terms of concurrency features? Is it similar to Actor model in Scala? Or based more on concurrent data structures as in java.util.concurrent.*?
Concurrency in Haskell is a big thing. At the lowest level, purity means there's a lot of opportunity for parallelization. Atop that Haskell has a really great green threads system and new GHC has a very, very performant IO manager for running them. It's GC'd so you do have thread-local pauses and they're not as nice as Erlang's actor-local GC. Atop that you've got a nice channel system, the best implementation of Software Transactional Memory around, and neat new libraries like LVish for doing eventual consistency in a very reasonable fashion.
[1] http://research.microsoft.com/en-us/um/people/simonpj/Papers...
I also like to learn concurrency in Haskell and don't know a thing about it (currently, I'm trying to go over Clojure concurrency features). So what you have mentioned regarding the LVish framework and Erlang's actor-local GC, green threading will give me a good starting point to poke around. Thanks again for your note!
[1]http://chimera.labs.oreilly.com/books/1230000000929
Standard Chartered traders use an excel to Haskell interface for risk management and trade execution.
S&P Capital IQ uses a Haskell DSL called Ermine for their reporting engine.
Tsuru capital is the largest hedge fund to use Haskell for trading but there many smaller shops like Alpha Heavy Industries.
http://www.haskell.org/haskellwiki/Haskell_in_industry
FP Complete repeatedly mentioned Standard Chartered's Excel to Haskell system as something that they would want to see more widely adopted.
I'm a big fan of new tools to make mathematical models for traditional investing, but I am fairly against the idea and practice of HFT.
For #1 you need quantitative finance. #2 is the activity known as "market making" and HFT is what you get when you automate it and then let the people doing it compete. The algorithms in HFT are pretty simple-minded; the goal is to offer as thin a spread between buying and selling prices as you can while still making a profit, and to offer it faster (when someone comes looking to trade) than anyone else. The latter is genuinely useful when it's the difference between (say) 5 minutes and 5 seconds. Unfortunately the same incentives that make it worth while for high-frequency traders to offer sub-second response times then make it worth while for them to keep chasing faster and faster times, until the most important asset a HFT shop has is a bunch of computers positioned slightly closer to a big exchange than anyone else's.
There's not much of what people mostly mean by "quantitative finance" in a typical HFT system, I think.
Take a look at: quantstart.com He has some tutorials with Python to do so, and he is releasing a book (hopefully soon) that should give you a good overview of it all. Also, I recommend you read Options, Futures and Other Derivatives to understand how most of this financial instruments work. There is a lot of good information there.