4 ms·

My take aways from the talk: 1. Financial transactions are adversarial and have heavy tails. Testing is not sufficient for Universal Guarantees, type system he

by sremani 11y ago

My take aways from the talk: 1. Financial transactions are adversarial and have heavy tails. Testing is not sufficient for Universal Guarantees, type system helps here. 2. Whole class of trivial bugs are not there because of Option (Some, None) and SystemF type system 3. Type system should be part of design process (which happens in OCaml) 4.Precise and Expressive type systems. 5. Right tool for right job, but with OCaml is in sweet-spot to write huge range of programs * little scripts * mini langs for configs * big trading system 6. Teaching/Learning: * a good percentage of traders with a month long bootcamp were able to learn with a good level of competence * MIT and Harvard students were able to achieve competence in 3-4 week internships. 7. The "python" paradox, esoteric language development helps attract high-quality/better talent 8. Tools and libraries OCaml would not be great if you have to reinvent lot of libraries ala. web development, but has good reasonable ecosystem for customized solutions (like trading systems etc.)

solipsism 11y ago
I'm not sure I understand the adversarial part or why that should matter. He mentioned it being a zero-sum game, with some having to lose for others to win. I don't get why that's relevant to the programming language choice. I think what he should have said is that financial transactions are important, and that it's expensive to screw up. This is of course as true or more for, say, NASA's flight software (which is not problem that's not adversarial in the way he means) as it is for financial trading software.
- jleader 11y ago
  The difference is that if NASA screws up, there's a certain percentage chance that the bug will be exposed, and cause a problem. That percentage usually stays constant over the lifetime of the system, regardless of how many times the bug has already bitten them. In an adversarial situation, there's a percentage chance that the bug will be exposed, and after that a 100% chance that adversaries will exploit it.
  - mmsmatt 11y ago
    Pick up "Capital Markets for Quantitative Professionals" - a great resource - and get a taste of this as early as the preface! The author writes about a bug he introduced in a program making markets in treasuries. It cost his firm $30k every trade, and the errant trades piled up as other participants recognized his mistake.

by sremani 11y ago

solipsism 11y ago

I'm not sure I understand the adversarial part or why that should matter. He mentioned it being a zero-sum game, with some having to lose for others to win. I don't get why that's relevant to the programming language choice. I think what he should have said is that financial transactions are important, and that it's expensive to screw up. This is of course as true or more for, say, NASA's flight software (which is not problem that's not adversarial in the way he means) as it is for financial trading software.

jleader 11y ago
The difference is that if NASA screws up, there's a certain percentage chance that the bug will be exposed, and cause a problem. That percentage usually stays constant over the lifetime of the system, regardless of how many times the bug has already bitten them. In an adversarial situation, there's a percentage chance that the bug will be exposed, and after that a 100% chance that adversaries will exploit it.
- mmsmatt 11y ago
  Pick up "Capital Markets for Quantitative Professionals" - a great resource - and get a taste of this as early as the preface! The author writes about a bug he introduced in a program making markets in treasuries. It cost his firm $30k every trade, and the errant trades piled up as other participants recognized his mistake.