Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An oral history of Bank Python (2021)

calpaterson.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: An oral history of Bank Python (2021)

#51

Post by alexpotato »

I've worked at a bank and several large hedge funds.

Some additional interesting tech stories I would add:

- in 2010, the bank had retail Good Till Cancel orders from 1997. I think one was "Buy INTC at $6"

- There is a mix of "I didn't know technology could do this" in the good sense and "I'm amazed this code a. works at all and b. hasn't had an outage in 6 years"

- There is a strong desire, I chose this word carefully, to migrate off of legacy systems. That being said there are several; big issues: 1. it's a GIGANTIC amount of effort with often unclear ROI to the business, 2. upside is capped (maybe you get a promotion) but downside risk is huge (you could tank the business with an outage). 3. Slow, gradual refactors are generally better here but some things can only be "big bang" for various reasons

- You tend to see old but performant and battle tested systems get retired in favor of shiny, new systems with lots of bugs. Why? It looks better on a resume to say "I retired old, crufty legacy system and rolled out a new system" instead of "I refactored old system to be better"

- The complexities are wild e.g. Korean trading requires: a. traders to be licensed in Korea (even if they are working in NYC), b. servers to be in Korea c. tagging orders with not only their executions but also the exchange rate at the time

- There are entire SYSTEMS built to track trade breaks (e.g. Bank A doesn't agreed with Bank B on fill 1248383). Some of these trade breaks are open for for YEARS due to litigation, companies going out of business etc

I could go on and on about this.

If anyone is ever interested in having me on a podcast to talk more about it, I would totally be up for it.

Re: An oral history of Bank Python (2021)

#52

Post by Maven911 »

elemeno wrote: post #8

To the best of my knowledge much of this originated with SecDB/Slang at Goldman - SecDB (securities db I believe) being the object store and slang the somewhat quirky C like language that ran with it (also the only language I’ve used professionally that let you have spaces in the variable names). Some of the folk that built that (or worked on it) ended up at JPM and Merrill where they built the Python centric version…

A lot of them retired too and enjoyed making bank producing a pile of hot mess that the rest of the higher ups did not fully appreciate the mess they were producing. Collected their multi million packages and left

Re: An oral history of Bank Python (2021)

#53

Post by kayo_20211030 »

Thrymr wrote: post #15
elemeno wrote: post #8

To the best of my knowledge much of this originated with SecDB/Slang at Goldman - SecDB (securities db I believe) being the object store and slang the somewhat quirky C like language that ran with it (also the only language I’ve used professionally that let you have spaces in the variable names). Some of the folk that built that (or worked on it) ended up at JPM and Merrill where they built the Python centric version…

JPM's version was Athena (not Alpha) [0] [0] https://www.slideshare.net/slideshow/managing-python-at-scal...

Aaah. I get it now. Athena -> Minerva.

Re: An oral history of Bank Python (2021)

#54

Post by kayo_20211030 »

rbanffy wrote: post #47
calpaterson wrote: post #46

Earlier quoted context omitted.

Interestingly, after writing this (some years ago) I spoke to some of the original authors. They had never used Smalltalk. So I suppose they invented this stuff independently

Could be. I got the same vibes with Zope, which is Python and has an object database underneath it. At the time I had the impression the idea was popular in finance.

I loved Zope (and ZODB). No matter what I said, I could never convince the higher-ups it was the way to go. In retrospect, they were probably right. But those technologies were magnificent.

Re: An oral history of Bank Python (2021)

#55

Post by roryirvine »

frays wrote: post #31

The previous discussion was fascinating: https://news.ycombinator.com/item?id=29104047 Does anyone working at one of these banks or similar know if this information still holds true? And have any of the banks started using uv yet? Or will they forever be using pip?

Back then, I was working on a project for a mid-market investment bank which aimed to build a self-service platform to host more "standard" python apps whilst still allowing them some of the benefits of what TFA refers to as Bank Python (speed of deployment, ability to spin up short-lived experiments with minimal hoop-jumping, structured data model, etc).

There was certainly a widespread understanding that doing things the "Bank Way" made recruitment difficult, and they hypothesised that it was also a significant drag on their ability to turn around new projects. The main goal of the new platform was to provide an alternative way of doing things which would allow them to quantify that drag.

I know that the pilot was completed, and it went on to a more widespread deployment - but my involvement with it had already ended so I can't say if it actually proved their hypothesis / provided the quantitative data they wanted.

Re: An oral history of Bank Python (2021)

#56

Post by simonh »

tsukikage wrote: post #14

When first encountering these ecosystems and looking at the various pieces they contain, one may repeatedly ask: "why didn't they just use for this problem instead of writing this component/subsystem from scratch"? The answer is often that the battle-hardened mature off-the-shelf solution did not exist at the time the code was written. You're doing software archaeology.

Very much so, I worked on Quartz at BAML for a few years.

The whole idea was actually to use as much existing Open Source technology as possible. Hence Python and it's rich library ecosystem, instead of something home grown like SecDB/Slang. This was supplemented with proprietary infrastructure and libraries only where there was a clear need. For example a Directed Acyclic Graph library to ease migrations from the Excel sheets used by Quants. The distributed object store was pretty neat.

You could code up a basic web service with minimal functionality and have it running in nonprod in an afternoon, and then production the day after. All that boilerplate stuff was super low friction, so you could spend much more of your time on solving the actual problem.

Re: An oral history of Bank Python (2021)

#57

Post by simonh »

elemeno wrote: post #8

To the best of my knowledge much of this originated with SecDB/Slang at Goldman - SecDB (securities db I believe) being the object store and slang the somewhat quirky C like language that ran with it (also the only language I’ve used professionally that let you have spaces in the variable names). Some of the folk that built that (or worked on it) ended up at JPM and Merrill where they built the Python centric version…

I worked on Quartz at BAML for 4 years, it was great. I met Kirat Singh once when he visited the UK, he took the basic concept from Goldman to JPM, then to BAML.

Re: An oral history of Bank Python (2021)

#58

Post by nxobject »

Havoc wrote: post #12

I've seen similar inside large financial orgs - what struck me was how there are these huge amounts of people that spend their entire working life inside this alternate IT reality. It's not unlike SAP consultants where their skillset is tied to one company. Also...these things tend to have fuckin terrible documentation. Good luck figuring any of this out. And you can't google it and your AI is just as lost as you

> Also...these things tend to have fuckin terrible documentation. Good luck figuring any of this out. And you can't google it and your AI is just as lost as you

I convinced my boss to hire an intern for the summer to do this. They said: "wouldn't internship projects that involved actual coding be more attractive?"

I replied: "Well, they'll be having to do a lot of experimenting to figure things out..."

Post reply on HN