Live data from Hacker News

An oral history of Bank Python

calpaterson.com

221–230 of 333 posts

Re: An oral history of Bank Python

#221

Really interesting read. From what's described: Walpole (distributed job runner), Dagger (DAG that recalculates when dependencies change), Barbara (global key value store) and monorepo/fast deployment, its not so different from some big tech companies.

At JPM, Athena: Walpole = Bob job runner Dagger = pixies Barbara = hydra The python 3 migration is still ongoing

Jesus I can imagine how difficult it is to migrate the whole solution to Python3.

Re: An oral history of Bank Python

#222
post #152

> I've mentioned that programmers are far too dismissive of MS Excel. You can achieve a awful lot with Excel: more, even, than some programmers can achieve without it This is one of the most underrated topics in tech imho. Spreadsheet is probably the pinnacle of how tech could be easily approachable by non tech people, in the "bike for the mind" sense. We came a long way down hill from there when you need an speciali…

problem as described to me is that excel starts being used for regulated processes and it's not well auditable, access controlled, changed controlled, tracked, etc etc. Then people need to implement the exact same process across departments and they're all using a separate excel sheet and they all submit different numbers. becomes a huge mess and so much more complicated and expensive systems become commissioned.

There's an excellent example of this phenomenon in the JPM "London Whale" report where -- at various points -- poorly maintained and validated spreadsheets appear as minor villains in a $6.2bn loss.

Re: An oral history of Bank Python

#223
post #98

Earlier quoted context omitted.

Can you have a career in finance as an engineer with Python and without C/C++ (professional) experience? Your post really made think it, it's an attractive area to work in.

Absolutely yes. Depending on what kind of engineer, it is far better to go to the finance (front office quant, back office risk) side than the tech support side. They are less snobbish about autodidacts and pay is far better if you are willing to learn about things outside the dev sandbox. (Our front office has a few quants and ex-quants with electric engineering background, I don't know of any software engineers the…

Thanks for detailed pointers. What's the deal with front/back offices?

Re: An oral history of Bank Python

#225
post #20

I can see the benefits of this collection of tools within an all-in-one monolith. Ease of deployment is a big benefit. I can also see the costs. As a stack its probably better in some ways than how a lot of other businesses operate as well as worse. There's probably a lot both ways. The mainframe mindset might be a factor here as well. The giant mainframe where all the magic happens is still a thing to behold and thi…

> The part about programming languages frequently not having tables is interesting. The closest as mentioned is the hash, but you lose so much in that abstraction eg the relational aspects. The counter argument then becomes the obvious: why aren't you using a database library, or in a pinch, sqlite? Rightly so. Why would you add relational tables to python rather than have a generic python database spec or a collecti…

Funny thing is, databases were tightly integrated into programming languages all the way back in 80s - that's exactly what dBase was, and why it became so popular. FoxBASE/FoxPro, Clipper, Paradox etc were all similar in that respect.

And yes, it made for some very powerful high-level tooling. I actually learned to code on FoxPro for DOS, and the efficiency with which you could crank out even fairly complicated line-of-business data-centric apps was amazing, and is not something I've seen in any tech stack since.

Re: An oral history of Bank Python

#226
post #197

Earlier quoted context omitted.

Curious why would this high-powered person go to bat for a technology decision they didn’t seem to have done any risk assessment of? Wouldn’t he be liable if something was exploited and hurt and company, like his head would be on the chopping block for giving the go ahead when they traced it up the chain of command?

That's precisely why he did it the way he did. He had total deniability. Here's how the conversation would go if it went wrong somehow: "Armen, did you tell Sean to install python?" "No". "Sean, did Armen tell you to install python?" "Err... no. He said I probably wouldn't be fired." "Well it turns out he's not right about everything. Here's a cardboard box for your things."

This is only my opinion, but I think the reason Armen said it like he did was because by not making it an order he's giving Sean the option of not doing it, if he's not up for accepting the risk. However the risk was both of them could have got fired.

Armen must have known people would know Python had been put on these machines and that he authorised it, in fact what's the point of putting it on them if nobody knows and nobody uses it? I can guarantee you that within 24 hours someone was asking Armen why he'd authorised this and was justifying it. There cannot have been any possibility of dodging responsibility for this decision. If anyone got fired it would have been Armen, with a possibility of Sean going as collateral damage.

This is the big league. You make your decisions and you accept responsibility for them.

Re: An oral history of Bank Python

#227

Earlier quoted context omitted.

Or they could use instead use CSVs. What could possibly go wrong?

Everything is fine, as long as no Americans come and write 1,000 where obviously they should have written 1000 or 1'000. /s

Or those pesky Europeans writing 12,34 when they obviously meant 12.34!

Re: An oral history of Bank Python

#228
post #29

Earlier quoted context omitted.

Hmm, I found the opposite - the fact that there was this global framework that managed all the data and code meant that access control was actually pretty good, better than most tech companies I've worked for. You had a single source of truth for what your access rights were, there was integrated Kerberos any time you needed to access a system outside Minerva. And having all the code in a managed place meant good dep…

This was 100% my experience too. The biggest productivity gains were: - having a single source of truth for both data and code (in a closely coupled environment) - strong, battle-tested libraries to take care of all infrastructure concerns. - enforced code dev/test/review/deployment workflows This let the front-office devs be highly productive on adding real business value for their trading desks. Remember also that…

> Remember also that these systems at GS, JPMorgan and BAML started around 2007-2010.

GS had „these systems“ well before 2000 (via J Aron). I think around the time you mentioned they spread to other firms (in their Python reincarnation).

Re: An oral history of Bank Python

#229
There's a lot here in common with the higher-prestige systems operated by major tech companies. Giant custom monorepos, sometimes with custom IDEs built into them. Big proprietary services for running asynchronous jobs and collecting logs and everything else. Data-driven frameworks for spinning up new services. Bespoke databases. All of it rings a bell.

The one thing in there that really jumped out at me as "oh my god never ever do that" was using pickle for serious persisted data. I can see the upside around letting people who aren't dedicated programmers avoid thinking about serialization but...daaamn. My understanding is that this locks you into a "the API is all the code" situation where you can never change the data layout of any class once you've written it?

Re: An oral history of Bank Python

#230

I was the person who first deployed Python at Goldman Sachs. At the time it was an "unapproved technology" but the partner in charge of my division called me and said (This is literally word for word because partners didn't call me every day so I remember) Err....hi Sean, It's Armen. Uhh.... So I heard you like python.... well if someone was to uhh.... install python on the train... they probably wouldn't be fired. O…

Armen was very passionate about the value of "strats" (GS's own term for "quants", and later broadened to include software engineers and data scientists). A favorite quip of his: At GS, I'm like an arms dealer. When a desk has a problem, I send in the strats, and they blow away all the competition! Also, SecDB's core idea is not just tight integration between the backend and development environment, but that all obje…

It's as old as VisiCalc, it's how spreadsheets work.

I built a similarly reactive system for web UI binding back in 2004, running binding expressions on the back end with cached UI state to compute the minimal update to return to the front end, in the form of attributes to set on named elements.

Post reply on HN