An oral history of Bank Python
calpaterson.com
An oral history of Bank Python
1–10 of 333 posts
Re: An oral history of Bank Python
#2Somehow reading this article really made me think of lisp and some old jane street and k lang articles here on hn over the years. I wonder if it’s the composability or the centralization?
Re: An oral history of Bank Python
#3Compared to one major IB bank Python system, this is all extremely clean and neat.
Consider a Python API that is a thin wrapper on COM calls intended to be used from Excel. Want to request some data? Fill in a 2D virtual Excel table. Want to pull some data? Query it and parse a text-dump of a table excerpt (remembering to parse #NA! Etc as nans). Want to automate a job? Enter it as a new row to a global spreadsheet. And for Gods sake, do NOT edit any of the other rows, lest the whole house go down in flames!!!
Re: An oral history of Bank Python
#4Doesn't seem that strange compared to K[1] or Q[2], which are used by Wall Street banks. K encourages you to use single-letter variables and bunch your code up as tight as possible into long lines. Here's an example: [3]. Interestingly, their Github repo has some K-inspired C[4], Java[5], C#[6], and Javascript[7].
[1] https://en.wikipedia.org/wiki/K_(programming_language)
[2] https://en.wikipedia.org/wiki/Q_(programming_language_from_K...
[3] https://github.com/KxSystems/kdb/blob/master/holiday.q
[4] https://github.com/KxSystems/kdb/blob/master/c/c/odbc.c
[5] https://github.com/KxSystems/kdb/blob/master/c/jdbc.java
Re: An oral history of Bank Python
#5I 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 this is definitely part of banking's history and present. Mainframes are beasts and are still far from any kind of obsolescence. A monolithic Bank Python with a standardised set of libraries etc would slot right in to that mindset and way of thinking.
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 collection of database connector libraries. Databases are separate and large projects in themselves.
I'd still be overly disturbed if they were running some old python 2.5 or similar. Just saying. That would be a source of pity.
Re: An oral history of Bank Python
#6Sounds like the Quartz platform at Bank of America. When I interviewed with that team they joyfully espoused the virtues of their Principal Engineer who quote, “created the database software from scratch!”
Edit: For the record, I implement third-party vendor Excel functions (DLLs written in C++) in C# and it’s a great way to send useless processes to the shadow realm.
Re: An oral history of Bank Python
#7Compared to one major IB bank Python system, this is all extremely clean and neat. Consider a Python API that is a thin wrapper on COM calls intended to be used from Excel. Want to request some data? Fill in a 2D virtual Excel table. Want to pull some data? Query it and parse a text-dump of a table excerpt (remembering to parse #NA! Etc as nans). Want to automate a job? Enter it as a new row to a global spreadsheet.…
Or they could use instead use CSVs. What could possibly go wrong?
Re: An oral history of Bank Python
#8sounds like a company dealing with ..
Re: An oral history of Bank Python
#9Sounds like it could be JPM's 'Athena' platform?
context: https://www.techrepublic.com/article/jpmorgans-athena-has-35...
Re: An oral history of Bank Python
#10This pattern in large part came from SecDB at Goldman, and then a few people who moved to moved to JPMC and BAML.
Dependency graphs are an elegant solution to risk management and pricing etc. There’s a reason this approach works in IBanks.
Check out Beacon.io which is the a SaaS implementation from the same team.