Live data from Hacker News

What the interns have wrought, 2020 edition

blog.janestreet.com

161–170 of 219 posts

Re: What the interns have wrought, 2020 edition

#161
post #4

For those who don't know, Jane Street is one of the best performing algorithmic trading firms on Wall Street. Probably the largest Ocaml shop on earth. It's a lucrative job for strong programming talent. Engineers there routinely make well over $1mm/year (edit: after a few years). They are similar to Two Sigma in tech focus and talent, which is a more well-known firm.

When we say "algorithmic trading" is this synonymous to "high frequency trading"?

Technically HFT is a subset of algorithmic trading. Algorithmic trading can be done on both the buy (IE hedge fund) and sell (Investment bank) side, but does not need to be high frequency. High Frequency also means low latency- sub millisecond, and I have never seen an algo trading system of any sort that deals in latencies that are not in the millisecond range, though this isn't really a requirement.

Does this help?

Re: What the interns have wrought, 2020 edition

#162
post #146

I know a guy who works at Jane Street; he was formerly one of the brightest undergrads at Caltech. He turned down an offer to do a PhD at Berkeley to take the Jane Street offer, IIRC. He is pretty idealistic and has an interesting philosophy about working in finance: he thinks moving money around isn't that societally valuable, but he donates 10-15% of his income to charity each year (I think he picks charities using…

> moving money around isn't that societally valuable I would say hedge funds have massive negative social value (especially quant/HFT ones), and actively contribute to wealth inequity. Robert Mercer is a prime example of this. Not saying I think your friend is a bad person or should quit, but it's kind of a naive justification.

Robert Mercer is a great example of this. He’s use his resources to helped us question the norm and accepted.

Science progresses because all willing to accept new ideas. Are they always right? No, but it can become dangerous when people are afraid to think for themselves, like Copernicus and the Catholic Church.

As humans, we must explore and exploit; Mercer chooses his path as he rightfully can.

Re: What the interns have wrought, 2020 edition

#163
post #34

Earlier quoted context omitted.

Yep, and they use OCaml! I always feel like I have to point it out since people do not think much of it, have lots of misconceptions of it, and so on.

I guess I might have some misconceptions of OCaml. Are there other companies that use it? I ask because whenever someone says "OCaml is used in industry, for example, Jane Street", they say it like it's just one example, but it's always Jane Street.

I worked at a startup (Amplidata) where we build a distributed storage system in OCaml. It got acquired by Western Digital, which later sold it to Quantum. Afaik, there is still development going on using OCaml.

Couple of things I took away from the experience:

- After an initial ramp-up, most of the developers liked or even loved the language. Downside was the limited tooling/libraries (2010-2015, seems better now).

- Quality of the resulting product was quite high: bug rate was fairly low, especially once experience with the language increased. Turns out sum types, gadts and the module system (functors) are very powerful to express invariants and design composable logic.

- OCaml was successfully picked up by team members without a formal computer science background, or even without a lot of programming experience. Not that it turns everybody into a great programmer, but it seemed to coerce new hires into delivering a working feature, without a huge risk of breaking a lot of other code.

- It is still possible to write crappy / unmaintainable code. But in OCaml it is often as easy (or even easier) to write good code.

- If something did turn out to be broken, it was painful. Debugger support (GDB) was initially non-existent. Under heavy load, we triggered a couple of bugs in libraries, which was quite painful to fix. On the other hand, we also triggered bugs in malloc and in the Linux kernel, which were as painful, so it might have had more to do with the high-load scenario, than with OCaml.

- For really low level stuff, or very high-performance cases, we did need to use the escape hatch to call C code. Interfacing Ocaml with C was not the most pleasant (was before ctypes library). Debugging bugs at that boundary was extremely unpleasant. One trigger for this was the fact that multicore OCaml never materialized, which also damaged the "political position" of OCaml within the company.

- Management (especially after the acquisition) was at best indifferent, and at worst hostile towards it. OCaml was perceived as being difficult to hire for (or outsource). Using more "standard" languages like Java, C++, Python was seen as the safer bet. They tried and often failed (C++ turns out to be damn complex, and maintaining a large Python codebase turned into whack-a-mole, but for bugs.).

Re: What the interns have wrought, 2020 edition

#164

Earlier quoted context omitted.

When we say "algorithmic trading" is this synonymous to "high frequency trading"?

Technically HFT is a subset of algorithmic trading. Algorithmic trading can be done on both the buy (IE hedge fund) and sell (Investment bank) side, but does not need to be high frequency. High Frequency also means low latency- sub millisecond, and I have never seen an algo trading system of any sort that deals in latencies that are not in the millisecond range, though this isn't really a requirement. Does this help?

Yes. So seller A wants to sell for $1.00 and buyer B is willing to buy at $1.06, an algorithm will calculate the presence of this potential (or actually have knowledge from other systems that this a certainty) and purchase seller A's stock with a margin of overhead of $1.03 and sell to buyer B for $1.06 netting $0.03.

The algorithm is essentially a parasitic entity.

Re: What the interns have wrought, 2020 edition

#165

Earlier quoted context omitted.

Technically HFT is a subset of algorithmic trading. Algorithmic trading can be done on both the buy (IE hedge fund) and sell (Investment bank) side, but does not need to be high frequency. High Frequency also means low latency- sub millisecond, and I have never seen an algo trading system of any sort that deals in latencies that are not in the millisecond range, though this isn't really a requirement. Does this help?

Yes. So seller A wants to sell for $1.00 and buyer B is willing to buy at $1.06, an algorithm will calculate the presence of this potential (or actually have knowledge from other systems that this a certainty) and purchase seller A's stock with a margin of overhead of $1.03 and sell to buyer B for $1.06 netting $0.03. The algorithm is essentially a parasitic entity.

Can you explain to me very carefully why the orders of seller A and buyer B weren't able to match before Mr. Evil HFT came along?

Moreover, given that buyer and seller weren't able to match without Mr. E. HFT's help, hasn't he in fact rendered a valuable service (for which he should, of course, be paid)?

Re: What the interns have wrought, 2020 edition

#166
post #89

Earlier quoted context omitted.

>but most of the world runs fine most of the world doesn't run fine. If airplanes were built like your average software stack they'd drop out of the sky every other day. Development practise at a place like JaneStreet is an example how things ought to be done. I really dislike the analogy of Ocaml as some sort of esoteric billionaire tool. It's just a sound language that everyone can understand, it's not even particu…

> If airplanes where built like your average software stack they'd drop out of the sky every other day. I missed to add C/C++ to my list. That would have covered real time systems you mention. > Development practise at a place like JaneStreet is an example how things ought to be done. As much I agree Jane street is doing cutting engineering for their domain, it seems unrealistic that rest of the world is unaware of g…

> it seems unrealistic that rest of the world is unaware of good software engineering in generic use cases.

Depends on who is aware and whether they have the clout to actually implement it, the trenches are full of developers who know there are better ways and that those better ways would have a positive RoI but that it wouldn't show up possibly for 3-4 quarters minimum which makes it a hard sell to management if you can get them to even understand it without a tortured analogy - those programmers frequently don't have the authority to enforce the standards particularly when the other half in the trench with them are busy adding to the pile or actively fighting against it.

There have been times where I've wanted to shiv (figuratively) a developer who writes the worst most pointless convoluted code after he proclaimed code should be "self documenting".

Fortunately these days I'm at a level where at least for my teams I can enforce whatever standard we agree on and if we can't agree then the one I agree on - if we can't reach a consensus I operate on democratic principles, one man, one vote - I'm the man, I have the vote (though I try to avoid having to do that).

Re: What the interns have wrought, 2020 edition

#167
post #165

Earlier quoted context omitted.

Yes. So seller A wants to sell for $1.00 and buyer B is willing to buy at $1.06, an algorithm will calculate the presence of this potential (or actually have knowledge from other systems that this a certainty) and purchase seller A's stock with a margin of overhead of $1.03 and sell to buyer B for $1.06 netting $0.03. The algorithm is essentially a parasitic entity.

Can you explain to me very carefully why the orders of seller A and buyer B weren't able to match before Mr. Evil HFT came along? Moreover, given that buyer and seller weren't able to match without Mr. E. HFT's help, hasn't he in fact rendered a valuable service (for which he should, of course, be paid)?

So that's the missing part you say? The Internet has been the biggest catalyst of disintermediation in history. But this is not disintermediatable without HFT?

Re: What the interns have wrought, 2020 edition

#169
post #165

Earlier quoted context omitted.

Yes. So seller A wants to sell for $1.00 and buyer B is willing to buy at $1.06, an algorithm will calculate the presence of this potential (or actually have knowledge from other systems that this a certainty) and purchase seller A's stock with a margin of overhead of $1.03 and sell to buyer B for $1.06 netting $0.03. The algorithm is essentially a parasitic entity.

Can you explain to me very carefully why the orders of seller A and buyer B weren't able to match before Mr. Evil HFT came along? Moreover, given that buyer and seller weren't able to match without Mr. E. HFT's help, hasn't he in fact rendered a valuable service (for which he should, of course, be paid)?

[deleted]

Re: What the interns have wrought, 2020 edition

#170
post #165

Earlier quoted context omitted.

Yes. So seller A wants to sell for $1.00 and buyer B is willing to buy at $1.06, an algorithm will calculate the presence of this potential (or actually have knowledge from other systems that this a certainty) and purchase seller A's stock with a margin of overhead of $1.03 and sell to buyer B for $1.06 netting $0.03. The algorithm is essentially a parasitic entity.

Can you explain to me very carefully why the orders of seller A and buyer B weren't able to match before Mr. Evil HFT came along? Moreover, given that buyer and seller weren't able to match without Mr. E. HFT's help, hasn't he in fact rendered a valuable service (for which he should, of course, be paid)?

The HFT needs latency low enough to win a race against B.
Post reply on HN