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

An oral history of Bank Python

calpaterson.com

Post reply on HN
Print view View original

91–100 of 333 posts

Re: An oral history of Bank Python

#91

Post by simonh »

curiousgal wrote: post #77
simonh wrote: post #72

Earlier quoted context omitted.

I think Minerva is clearly a reference to Athena.

Could be a misdirection because all of the rest fits Quartz to a tee. The Quartz database is called Sandra (referred to as Barbara here). The Quartz directed acyclic graph is called Dag (referred to as Dagger here) The Quartz job runner is called Bob (referred to as Walpole here which is a reference to Robert Warpole whose shortname is..Bob) These and the horrible proprietary IDE make it obvious which particular syst…

I think Athena has equivalents to all of these but I don't know what they're called. I only know Qz.

Re: An oral history of Bank Python

#92

Post by danmur »

andrewshadura wrote: post #81
lmm wrote: post #19

I'm seeing a lot of people speculating about which bank this might be; I think the point is that it's all of them. I could loosely describe a previous job as implementing Morgan Stanley's Walpole and integrating more source code management into Minerva (even though that system wasn't actually Python-based). Having a global view on everything is large banks' value-add, it's why they haven't been outcompeted by their m…

> python build, dependency and deployment management is exceptionally awful in every respect, this isn't as big a pain point in other languages I'm not sure how to react to that, but these features in Python are miles ahead of what many other languages have (or actually don't have).

I think there are too many options, or not enough direction for busy people. Once you understand how it all works and pick / build the right tools it all works pretty well.

Re: An oral history of Bank Python

#93

Post by simonh »

JoshTriplett wrote: post #80
seanhunter wrote: post #21

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…

There are a number of workplaces where I'd have been willing to rely on "probably wouldn't be fired", but a bank is definitely not one of them. Congratulations on shipping something useful in the face of that risk and uncertainty.

The trading community walk on a knife edge all the time, it's not a place for the faint of heart. I used to support derivatives trading systems and a few times there were issues that meant they'd lost control of orders on an exchange. Scary stuff. It requires a crazy mixture of careful, deliberate, calculated risk control on the one hand; but once you commit to something you jump in with both feet and throw everything into it.

You need to be both meticulously risk averse, and also willing to do whatever needs to be done when it needs doing, and accept responsibility. It was great!

Re: An oral history of Bank Python

#96

Post by natpat »

Completely off topic - but I love the aesthetic of the post. "Vanilla HTML" is a design that isn't used enough. It's something I tried to apply to my personal blog, but I think it's been done much better here.

Re: An oral history of Bank Python

#97

Post by alecco »

Paladiamors wrote: post #74
simonh wrote: post #31

Earlier quoted context omitted.

I worked on Quartz for 3 years and loved it. Some devs grumbled about various aspects of it, but I come from an application support background and taught myself python, so I suppose I had fewer developer habits to un-learn. From what I understand, all this started with SecDB at Goldman, which was a the prototype for all these systems but wasn't Python based. The lore is that SecDB was instrumental in Goldman being ab…

I work at Beacon.io and it's an awesome place to be. Kirat is indeed a rockstar and it's awesome to work with an CEO that knows great code. We also landed a Series C last month and we're growing :) https://www.crunchbase.com/funding_round/beacon-series-c--60... We've also got a bunch of positions open too for those that are interested in joining! https://www.beacon.io/careers/

s/rockstar/primadonna

Build complex system, when things starts to get messy move somewhere else. Rinse, repeat.

Re: An oral history of Bank Python

#98

Post by odiroot »

urban_winter wrote: post #53

BAML Quartz was conceived by a bunch of front-office quants who had not the first idea about the software needs of a big bank beyond the front office. There was an arrogant assumption that front office software is obviously the most complicated/difficult variety of software within a bank and therefore any system designed with front office requirements at the forefront would, of course, be perfect for universal use. T…

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.

Re: An oral history of Bank Python

#99

Post by regularfry »

alecco wrote: post #86

I worked at one of the largest of these systems. It seems to be the one referred by the post. The global distributed store of pickled python objects using Event Sourcing was one of the most horrible and expensive database systems I've ever heard of. It runs on THOUSANDS of expensive servers with all data stored in-memory. To get the state of a single deal you had to open, decompress, deserialize, and merge hundreds i…

It looks like sound ideas, poorly implemented. A lot of these capabilities crop up in BEAM or Smalltalk. I do wonder if Erlang had better developer ergonomics we wouldn't have seen that instead of Python as a basis.

Re: An oral history of Bank Python

#100

Post by JackFr »

carnitine wrote: post #58

Always funny to see the objections of new hires without finance experience to the use of floating point for pricing. It’s more related to the inherent inaccuracy of any pricing model though, rather than clients not caring about pennies.

I remember someone demanding that we needed to run our Monte Carlo pricer on 1024 paths, that 256 just wasn’t precise enough and one of the risk guys said “Well since we know our assumptions are wrong I’m not sure what difference it makes.”
Post reply on HN