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

171–180 of 333 posts

Re: An oral history of Bank Python

#171

Post by carnitine »

Chris2048 wrote: post #131
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.

Can cause issues if you are accounting for things, e.g. "The sum of these values need to equal the sum of these values" In that case you'd then needs to avoid "sum_a == sum_b" and use instead "abs(sum_a - sum_b) < SOME_SMALL_VALUE"

You don’t do that though, there’s no use case to account with the output of a model.

Re: An oral history of Bank Python

#172

Post by hcarvalhoalves »

This seems baroque but I quite like the idea, seems similar in spirit to having a shared LISP environment where you can live code and snapshot images with minimal hassle. I also see as an improvement over the usual Excel mess, in particular there’s some version control and automatic propagation of changes.

Re: An oral history of Bank Python

#173

Post by anentropic »

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…

Ah, now I finally know what it means when I get job ads for Python+Quartz ...!

I could tell from the context it was nothing to do with QuickTime...

Re: An oral history of Bank Python

#174

Post by rlewkov »

oxfordmale wrote: post #43

I worked for a hedge fund that build their own database on top of MongoDB. Data was serialised and stored as binary blobs. This bonkers implementation took away any advantage of using MongoDB. Unfortunately this system had a lot of political backing, and rather than addressing the short comings we were told to simply datasets to ensure they could be stored in this bespoke database. I suspect a lot of trading signals…

Are you talking about Arctic from Man AHL? https://github.com/man-group/arctic

Re: An oral history of Bank Python

#175

Post by helsinki »

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…

Ha, cool. I learned Python on your distribution ca. 2014.

Re: An oral history of Bank Python

#176

Post by disgruntledphd2 »

dwohnitmok wrote: post #170
qorrect wrote: post #161

> You can achieve a awful lot with Excel: more, even, than some programmers can achieve without it. I've heard this a lot, but have never really used Excel. What can it do that a programmer can't ?

By virtue of Turing completeness there's nothing you can do in Excel that you can't do in a program. It's all a matter of speed. Having seen Excel wizards work their magic before, the dizzying ways they can slice and dice their data with the help of a combination of GUI affordances, formulas, and hot keys is truly astounding. Often times a person could build out a full set of data and charts in half an hour that migh…

> Often times a person could build out a full set of data and charts in half an hour that might be something like > 100 lines of equivalent Python/Pandas code.

But only ten lines of R! (Excel is kinda awesome though).

Re: An oral history of Bank Python

#177

Post by [deleted] »

govg wrote: post #133
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…

For some context (as an ex-Goldman employee myself), "Armen" in the quote is most probably https://www.goldmansachs.com/insights/outlook/bios/armen-ava... , who has quite a legendary reputation within the firm for the work he's done. He was also one of the first to be hired as a "strat", which used to be how Goldman referred to its quants who sat between front office and tech systems and worked with both sides.

[deleted]

Re: An oral history of Bank Python

#178

Post by helsinki »

arthurcolle wrote: post #142
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…

I worked for GSAM for a bit as my first NAPA project - I guess you're referring to Armen Avanessians? Haha haven't heard references to the "train" in so long. Did you ever do any Slang/SecDB dev? I was mostly in FICC Tech so was pretty much slangin' slang most of my time there. JSI (Java Slang Integration) was just getting off the ground but there wasn't too much for the front office tech teams to do there until it w…

My former team, previously known as AIM, wrote JSI :)

Re: An oral history of Bank Python

#179

Post by airstrike »

qorrect wrote: post #161

> You can achieve a awful lot with Excel: more, even, than some programmers can achieve without it. I've heard this a lot, but have never really used Excel. What can it do that a programmer can't ?

WYSIWYG, in every sense of the expression. There's no written abstraction. You just see the data (and depending on how things are structured, sometimes the intermediate steps getting that data from point A to point B).

With code, you type the abstractions while imagining the data in your head -- and then check to see if the final result is the right one. The average user will usually litter the code with debug print statements to help understanding what's going on live

With Excel, you live in the runtime and you stare at the results of your "code" all of the time. The abstractions and the links between steps of the process either live in your head (because you know how that financial model works) or are buried in formulas in the most asynchronous of layouts (cell A1 may be the result of a calculation in cell Z99, for instance)

Re: An oral history of Bank Python

#180

Post by pphysch »

lmm wrote: post #20
sfgweilr4f wrote: post #5

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…

> The separate datastore is the problem to be solved here - databases, especially relational databases, are extremely poorly integrated into programming languages and this makes it really painful to develop anything that uses them.

Hence "Active Record" ORMs like Rails and Django being highly successful. They functionally embed the RDBMS into the language/app (almost literally if using SQlite), which is a huge boon for developer productivity...

...but also a significant footgun, because it means the database is now effectively owned by the Active Record ORM and its (SWE) team, and not by some app-agnostic data team.

Want to reuse that juicy clean data managed by Django? Write a REST API driven by the app; don't try to access the data directly over SQL, although it may be tempting.

Post reply on HN