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

231–240 of 333 posts

Re: An oral history of Bank Python

#231

Post by FabHK »

odiroot wrote: post #223
MagnumOpus wrote: post #196

Earlier quoted context omitted.

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?

Rule of thumb: the closer to the business (ie front office), the more money and stress.

(Front office deals with clients, and in this context comprises sales, trading, structuring. Middle office run control functions, reporting, risk, compliance, etc. Back office would be settlement, accounting, operations, etc.)

Re: An oral history of Bank Python

#232

Post by FabHK »

cyberpunk wrote: post #135

Both frontarena and murex use python as their “vb” kind of language. If you thought your deployment pipelines were weird, ours have included putting entire python apps into single strings and inserting them to an oracle db, where a fat windows client selects them and runs them on a windows python interpreter … via citrix… :/

Username checks out :-)

Re: An oral history of Bank Python

#233

Post by IshKebab »

kwertyoowiyop wrote: post #106
simonh wrote: post #41

Earlier quoted context omitted.

You could not be more wrong. Quartz has first class documentation, solid tooling, very well thought out and rigorous code review and access controls. Banks are regulated up to the eyeballs, so everything has to be audited and justified in detail. It's not nirvana, these are real working systems built by humans with human failings. There are tradeoffs. Not every application is suited to these sorts of platforms, but t…

For some reason people think everything is as good as it can be at FAANG and other big name tech companies, and everyone else just walks around with their pants down at their ankles bumping into walls until 5:00. It’s just not true.

I mean Google has Bazel which has reliable hermetic distributed builds with modern statically typed languages. I don't think this weird custom Python system is really in the same league. Barely even playing the same game.

Re: An oral history of Bank Python

#234

Post by FabHK »

trenchgun wrote: post #36
Thorrez wrote: post #4

Doesn'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_(programm…

Very interesting. I am feeling the urge to learn array processing languages. There is something very tempting.

Project Euler frequently has ultra-short solutions in K/J/whatever other single letter they’re using at the moment. It is quite intriguing, but ultimately I put too much store in readability, so decided not to pursue these.

Re: An oral history of Bank Python

#235

Post by IshKebab »

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).

That's just untrue. Maybe compared to C++ Python isn't too bad. But try something modern like Go, Rust or Deno. Python is light-years behind.

Re: An oral history of Bank Python

#236

Post by bloblaw »

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).

If you compare Python's deployment and dependency management to those of statically compiled languages like Go, Rust, Zig, or Nim, you quickly see the experience with Python is quite poor.

In all the above languages, you simply ship a statically compiled binary (often just 1 file), and the user needs nothing else.

With any sufficiently complex Python project, the user will need:

1. virtualenv 2. possibly a C compiler 3. recent versions of Python (and that keeps changing. 3.0->3.4 are "ancient", and 3.6 seems to be the absolute minimum version these days --- due primarily to f-strings) 4. Or you ship a dockerfile and then the users need 600mb of Docker installed

I sometimes joke that in the future every Python script will require a K8s deployment and people will call it "easy".

Python is a great language, but deployment is a massive pain point for the language.

When I know I am writing something that has to "just work" on a wide range of systems that I don't necessarily control, well I don't write the solution in Python. I pick Go, Nim, or Rust (Zig would be a good choice too).

Re: An oral history of Bank Python

#237

Post by keithalewis »

seanhunter wrote: post #212
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…

> 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 able to rapidly figure out what their exposure was during the 2008 crisis. Correct. We used python for a bunch of infrastructure stuff (eg distributing all of secdb to all of the places it needed to go). The actual pricing a…

My grandpappy always told me to cut out the middleman. Modern C++ was heavily influenced by the need to make it simple to use directly. If you are in the business of writing code instead of reminiscing, you can now leverage move semantics, lambdas, and smarter pointers to create software that is close to the silicon. Python might be great, but it sure is slow. Its success is founded on smart people making it easier for not so smart people to call C++ that does the heavy lifting.

Re: An oral history of Bank Python

#238

Post by keithalewis »

arthurcolle wrote: post #189
arthurcolle wrote: post #144

Earlier quoted context omitted.

Had a lot of fun pulling things out of MetaDir and recreating what seemed like "early history" of SecDB when I was there, was a lot of fun :D

the spirit of dubno lives on...

But does he? There seem to be a lot of people in the know on this thread. He seems to have disappeared after leaving BofA.

Re: An oral history of Bank Python

#239

Post by miohtama »

sandGorgon wrote: post #145
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…

Does everyone use a giant Pickle dump ? I mean - how big is that ? Petabytes ? I'm kind of surprised nobody monkey patched python serialisation to use a database (much like GitHub did with ssh key lookup in MySQL). What does the devops there look like ? Snapshot every minute ?

ZODB is the object oriented database as a giant pickle dump. Surprisingly, it works and scales wuite well. The downside is that non-Python tools cannot access it all.

https://zodb.org/en/latest/

Re: An oral history of Bank Python

#240

Post by brendoelfrendo »

denimnerd42 wrote: post #185
mtrovo wrote: 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.

The jargon for this is "user-developed application," and auditors do keep an eye out for these. Banks, from what I've seen at least, typically have some process to document these as they come up, replace them with supported solutions, and retire them. At least, that's the "happy path," where people are willing and able to get all that done before a big-three auditor comes in and tears you a new one.
Post reply on HN