I knew a few people who quit Goldman's because of Slang, although the reactive graph portion of SecDB carried over around the industry.
An oral history of Bank Python
281–290 of 333 posts
Re: An oral history of Bank Python
#282I have been a developer for eight years and yet I still get shocked about the places where Python will be used. I mean, it is my favorite language, but in the communities I gravitate towards (basically communities like HN) it has so many detractors for being dynamically typed, not being functional enough, being slow, etc, that sometimes I'm tempted to think maybe it's actually a guilty pleasure of mine, and that I sh…
People who make complaints like that are privileging their own personal aesthetics over pragmatism. Same mistake as the people who keep talking about perl being "dead" while they're deploying their production platforms on debian or red hat based systems and ignoring the fact that the packaging and release QA work for those distros is substantially dependent on - actively maintained by the distros in question - perl p…
Sounds like someone else is putting their personal aesthetics over pragmatism. Perl is a dead language walking, the fact that there are some tools it hasn't been worth rewriting doesn't contradict that.
Re: An oral history of Bank Python
#283Earlier quoted context omitted.
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/
I learnt Python via Zope in 2000, and attended the Zope Conference in Python that year.
Joined JPMorgan in 2010 to work on Athena, and immediately had a real sense of deja vu... Athena's Hydra object db (essentially an append-only KV store of pickles) felt like a great grandchild of Zope's ZODB.
Re: An oral history of Bank Python
#284Earlier quoted context omitted.
This immediately struck me when I was reading this article. To be honest, this whole paradigm seems absurdly fucking efficient for the developers. But I wonder about stuff like * What happens if the data model needs to change? If you need to move something from db["some/path"]? * How is it coordinated at a larger scale, how does everyone know what is running and how it interacts with everything else - can you figure…
> What happens if the data model needs to change? You write conversions and there's a registry where you register them to be picked up by the unpickler. If necessary you can also customize the logic that determines which version a given pickled datum uses to deserialize. There aren't so many guardrails when you're writing that stuff, but the infrastructure does its best to support you. > If you need to move something…
Thanks! Interesting stuff.
Re: An oral history of Bank Python
#285Earlier quoted context omitted.
I work at Beacon.io and it's an awesome place to be. Kirat is indeed a rockstar and it's awesome to work with an CEO that knows great code. We also landed a Series C last month and we're growing :) https://www.crunchbase.com/funding_round/beacon-series-c--60... We've also got a bunch of positions open too for those that are interested in joining! https://www.beacon.io/careers/
As a full stack quant dev who is struggling to go all-in on Beacon: Do people generally like to use Glint for complex applications? Are benefits of Beacon lost when interfacing from e.g. Angular? I'm afraid that professional frontend devs might be unwilling to work with a proprietary framework, but that's speculation from my side.
Glint is an integrated framework with the platform but it does not limit you to just using the framework. The platform is designed to be as extensible as possible, worry not about being locked in :)
Re: An oral history of Bank Python
#286> 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…
Reminds me of the investment banking dev cycle in the 2000s:
* trader writes a pricing "app" in Excel
* trader discovers MS Access db
* traders (plural) start copying around Access db files
* problems
* "IT" gets involved
* convert MS Access to oracle or sybase
* write some server process(es) in C++
* write some replacement front end (spend months arguing over best grid component to replace excel) in C++/MFC
* trading system emerges...
* rewrite in C#, Java
* etc.
Re: An oral history of Bank Python
#287I 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…
There was no single person that introduced python at Citigroup that I am aware of. It came in via a variety of teams mostly because of the fact that the alternative was perl, and no one wanted to write perl (yet somehow kdb was acceptable a few years later).
Re: An oral history of Bank Python
#288Earlier quoted context omitted.
This is only my opinion, but I think the reason Armen said it like he did was because by not making it an order he's giving Sean the option of not doing it, if he's not up for accepting the risk. However the risk was both of them could have got fired. Armen must have known people would know Python had been put on these machines and that he authorised it, in fact what's the point of putting it on them if nobody knows…
Exactly, so what is this Armen character getting out of this other than a potentially big amount of liability and unarticulated risk. The OP said he told people openly that Armen told him he could do it when asked. This makes no sense to me, what’s the upside to Armen? If he is business savvy, he needs to be gaining something in exchange for having his name thrown around by OP as signing off on this.
Money or less risk of losing money. Partners originate deals and/or manage risk. He was looking for accelerated process to make informed decisions.
Re: An oral history of Bank Python
#289Re: An oral history of Bank Python
#290> In order to deploy your app outside of Minerva you now need to know something about k8s, or Cloud Formation, or Terraform. This is a skillset so distinct from that of a normal programmer (let alone a financial modeller) that there is no overlap. This rang a bell. How did deployment become such an arcane skill?
> How did deployment become such an arcane skill?
Prior to industry wide "solutions" such as Docker, or rather linux namespaces and cgroups, there was no obvious process isolation, so "deployment" was copying tarballs or using Windows installers.
Also, investment banks want "support" from vendors, so hardware was either Windows servers (mostly for Exchange and AD), or Sun Solaris boxes.
So although linux cgroups came around 2006 (?) and namespaces in 2001 (?), banks didn't do too much with linux until after 2005 (when Redhat were providing the aforementioned 'support'). I don't think the 'industry' widely recognised the potential of cgroups and namespaces.