it has a bit of a smalltalk flavor, where the runtime is a memory image, with objects and data in a giant jumble.
There was also a giant investment bank system written in Smalltalk, so that may be a direct influence:
An oral history of Bank Python
61–70 of 333 posts
Re: An oral history of Bank Python
#62I worked on Quartz for a while as a contractor. Hated every second of it. Python version was old (2.4 if I remember correctly when 3.x was already the popular version). But that wasn't it. It was the proprietary version of everything in the stack that got me. Proprietary ide, source control, libs etc. I noted that none of the others who have been there for years have any transferable skills that can cary them out of…
[deleted]
Re: An oral history of Bank Python
#63Sounds like it could be JPM's 'Athena' platform? context: https://www.techrepublic.com/article/jpmorgans-athena-has-35...
They are all similar but in this particular case this is definitely BAML's Quartz.
Re: An oral history of Bank Python
#64it has a bit of a smalltalk flavor, where the runtime is a memory image, with objects and data in a giant jumble.
I had the exact same thought! A custom IDE with all the source stored in a database is extremely smalltalk, although here the source is stored in a shared DB (it seems), rather than a per-user DB as it is with a regular smalltalk image.
Re: An oral history of Bank Python
#65Earlier 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…
Well, I don’t know about Quartz. I worked with DB systems and they were awful in that regard. They worked, but largely because people stuck to convention. For example, changing scheduler jobs required submitting a change in Excel and having it approved (twice...) by someone. Except the table was world-writable and changes not logged. So in principle only your appropriate superior could approve change, in practice any…
Youch, that's nasty. I can completely believe it though, banks are huge unwieldy organisations. I spent a fair bit of time working with auditors though, so I know a huge amount of effort goes into rooting out things like that.
The thing is just because a team in a bank did this thing, that doesn't mean "The Bank" thinks that's a good idea. Like any company, banks are communities. I'm not making excuses, the fact this system wasn't properly architected is a failure of governance, but I've been on the other side of this trying to get teams to fix their problems and adopt resilient processes and procedures. Every offender thinks their service is special and their violation of the standards is justified.
Re: An oral history of Bank Python
#66I 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…
If you don’t mind me asking which year was this?
Re: An oral history of Bank Python
#67Doesn'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.
You mean like Numpy? =P
Re: An oral history of Bank Python
#68> Clubbing it all together
Wherever the author works, they employ a lot of Indians!
Re: An oral history of Bank Python
#69> Investment banks have a one-way approach to open source software: (some of) it can come in, but none of it can go out
I'd say thats how they see society and their role in it more generally. Doing God's work is a surprisingly directed graph. It applies also to the broader banking world, but investment banks being the most lucrative (when not bailed out) attract talented people that in principle can close the loop and return something important back (much more so than the "sleepy" commercial bank or credit union).
It would interesting if the above (potentially biased) view could be backed up by computing an open source leech ratio per industry sector. The amount of open source code used versus the amount contributed.
NB: a high leech ratio does not necessarily make you the worst offender. If your business model is evil no amount of open source contribution will wash it out
Re: An oral history of Bank Python
#70I 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…
> I suspect a lot of trading signals were lost this way. If you can prove & show evidence about this, I'm sure they will (grudgingly) accept the need to improve. Financial institutions are mostly risk-averse, "if it works, don't fucking fiddle with it!" They need something that will impact the bottom line in an (almost) direct way. I remember working with a financial institution back in 2010. I pushed for virtualizat…
It is very hard to prove you have lost trading signal. You would have to redo your backtesting, and would politically be fraud (high risk of getting sacked). Often trading systems will perform worse in the real world anyway compared to the simulations, so it generally can only be proven if there is a politically willingness to do so.