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

41–50 of 74 posts

Re: An oral history of Bank Python (2021)

#41

Post by valzam »

> One of the great drawbacks of "Cloud Native Computing" as it now exists is that it's really, really complicated. It is often more complicated than the old, non-cloud, sort of computing. In order to deploy your app outside of Minerva you now need to know something about k8s, or Cloud Formation, or Terraform.

Highly agree with this. I think it's very underappreciated in startups that if you want people to deploy a lot of small services you have to make that really super easy. I always thought that the value of things like Spark is that you can run "things" without having to worry about how they run. K8s is similar but much more complex. AWS Lambda is nice but also comes with a lot of baggage at scale. I always wanted to try something like Dapr, which seems to provide a very opinionated happy path for application development.

Re: An oral history of Bank Python (2021)

#43

Post by janosch_123 »

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

I was reading the article and got SAP/ABAP flashbacks.

- source code in database: yes

- own IDE for questionable reasons: you bet!

- custom table objects: we got your back.

- strange forks of common python libraries: would you like warnings with that?

Re: An oral history of Bank Python (2021)

#44

Post by neongreen »

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?

I worked at Standard Chartered and it's a bit similar, but it's hard for me to judge how much.

SC has its own Haskell compiler that produces bytecode that you can run locally, serialize, send to be executed somewhere else, etc. Most of the code still lived in a monorepo, though.

We did have a global data store (well, several) that any code could access. I was working on a more "normal" application that was still written in the SC haskell dialect but otherwise mainstream architecture -- postgres, deploying to a boring linux server, etc.

A colleague once described our dialect as "Python that looks like Haskell". This is an exaggeration, but a) we did use a lot of untyped dicts and everything-is-a-giant-relational-table structures, and b) my understanding is that the actual financial modelling was done in C++ and the SC Haskell was glueing things together. Idk.

About uv -- I did try to convert ppl to uv but it probably didn't spread further than my few colleagues at the Warsaw office.. well and also I merged a monorepo-wide documentation system that used sphinx and uv, but idk if it's still alive after I left.

Re: An oral history of Bank Python (2021)

#45

Post by lesam »

lmm wrote: post #17
skissane wrote: post #13

I think it is a pity they’ll likely never open source any of this stuff Of course, financial institutions have a lot of “secret sauce” - such as financial models - you’d never expect them to release. But this kind of underlying infrastructure isn’t really “secret sauce”

Morgan Stanley's version is open-source at https://github.com/morganstanley/optimus-cirrus , although I don't know how practical it is to actually run yourself. (They don't go quite as far as having the code itself be bitemporal and kept in the datastore, but most of the stuff in the article exists there)

Poetic that the most recent update is 6 months ago, a one line change adding a 'Lifecycle: Active' emoji to the Readme.

Re: An oral history of Bank Python (2021)

#46

Post by calpaterson »

rbanffy wrote: post #38
axus wrote: post #4

What a well-written account of "how things are done". > Time to drop a bit of a bombshell: the [Barbara] source code is in Barbara too, not on disk. Remain composed. It's kept in a special Barbara ring called sourcecode.

This makes it feel like a gigantic Smalltalk instance.

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

Re: An oral history of Bank Python (2021)

#47

Post by rbanffy »

calpaterson wrote: post #46
rbanffy wrote: post #38

Earlier quoted context omitted.

This makes it feel like a gigantic Smalltalk instance.

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.

Re: An oral history of Bank Python (2021)

#48

Post by Recursing »

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.

Zope was strongly influenced by Smalltalk

> The ZODB is an (almost) transparent python object persistence system, heavily influenced by Smalltalk.

https://zodb.org/en/latest/articles/ZODB-overview.html#compa...

I think Jim Fulton and other authors of Zope originally came from Smalltalk

Re: An oral history of Bank Python (2021)

#49

Post by ForHackernews »

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

Isn't Google like this, too? They have their own source control system, their own IDE, their own databases.

It seems like any giant organization eventually develops its own software center of gravity.

Post reply on HN