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

151–160 of 333 posts

Re: An oral history of Bank Python

#151

Post by kristjansson »

pmontra wrote: post #124
Icathian wrote: post #115

Earlier quoted context omitted.

I would agree for all but deployment. I know my way around python reasonably well, but pyinstaller and friends still make me have bad days pretty regularly.

Four Python projects, same customer, five different deployment systems. Docker, a Capistano look-a-like I coded in bash, git pull (their former standard), git format-patch plus scp, zip archives. Yes, python file.zip works if it contains the right files. Probably the latter is the easiest way, except it doesn't address the dependencies.

> except it doesn't address the dependencies

It does if you put them all in the zip :)

(and build for exactly the platform your customer is going to deploy on)

Re: An oral history of Bank Python

#152

Post by mtrovo »

> 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 specialist even to come up with a no-code solution to mundane problems.

Sure the tech ecosystem evolved and became a lot more complex from there but I'm afraid the concept of a non-tech person opening a blank file and creating something useful from scratch has been lost along the way.

Re: An oral history of Bank Python

#153

Post by tomrod »

seanhunter wrote: post #21

I 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…

Beautiful!

I worked a bit with Athena and was in the group that got Anaconda into the banking sector.

Small world we live in. I think I remember your name from JPMC days, but it has been awhile.

Re: An oral history of Bank Python

#154

Post by tomrod »

kwertyoowiyop wrote: post #108
captainmuon wrote: post #18

Reminds me of what we used at the ATLAS experiment at CERN* . Python was tightly integrated with the application framework, Athena (which I just realize has the same name as JPM's Python framework!). You could use it as a job description language, and you would compose computation steps from classes you could write in C++. I think there was a separate `athena` executable that was just python with some packages pre-lo…

The Greek and Roman gods have always been a go-to for project names, LOL. We need to give some other cultures a shot!

I'm a fan of Norse!

Re: An oral history of Bank Python

#155

Post by Mikeb85 »

simonh wrote: post #51
lozenge wrote: post #34

Earlier quoted context omitted.

Most licenses just require your users to have access to the source code. As all the users are bank employees, this is usually easily achieved. If the license is violated it's only by accidental oversight. Pretty much everything described is a Python library not a change in the Python interpreter so can be under a proprietary license. The spirit of open source is a different matter.

As I understand it from a legal point of view the user in this case is the bank, not individual employees running it on the bank's behalf, and the bank already has the code so it's a non-issue. I know some people think this is contrary to the spirit of open source, but it isn't. One of the goals of open source is so that users can customise the code to their specific use case, with no obligation to share. That's all…

This. Even RMS has said many times that a company is a single user/owner of said code, and it doesn't matter who works on it as long as it doesn't leave the company. It's all explained in the GPL but the gist is, if the company only uses it internally/doesn't try to sell the code, they can do whatever TF they want.

Re: An oral history of Bank Python

#156

Post by tomrod »

globular-toast wrote: post #49
eb0la wrote: post #39

Earlier quoted context omitted.

There are too many factors here. One of them is you don't own where your code runs anymore. This might scare some people until they realize they can get high availability without waiting 3 months for some server to arrive, but it makes deployment harder. I still believe the main reason people adopt CI/CD today is that "suddenly" deployment in a complex environment becomes easy and software gets tested. A lot.

> One of them is you don't own where your code runs anymore. That's not new. The first money I earnt from computers was making websites. We didn't own the webservers; we rented webspace from some company. To deploy it, we literally just uploaded PHP files to a place using an FTP client. It was that simple and it worked.

Your example highlights the value chain of CI/CD!

Re: An oral history of Bank Python

#157

Post by Mikeb85 »

streamofdigits wrote: post #87
globular-toast wrote: post #54

Earlier quoted context omitted.

As others have mentioned, it's fine, even with GPL, as the licences only really kick in when they try to distribute the software. They are only really hurting themselves. When starting a private fork you force yourself to maintain it alone. That means either letting it rot (ie. it becomes insecure and obsolete with no new libraries supporting it) or keeping up with the mainstream yourself. Either way it's a lot of wo…

what would be the implication wrt external banking services that use open source software? (echoes the cloud databases story...)

Are they distributing/selling the code? If the answer is no (and it pretty much always is) then there's no implications. Nothing in the GPL says you can't have a web front end to gather info that's then processed by your modified GPL code (which never leaves your possession) and the results spat back out to that web front-end.

Re: An oral history of Bank Python

#158

Post by igouy »

mumblemumble wrote: post #126

> There is an uncharitable view (sometimes expressed internally too) that Minerva as a whole is a grand exercise in NIH syndrome. My brief experience with this (in an adjacent area - proprietary trading) was that the more charitable view is that these firms need to be able to fully own their software stacks, and have the resources to pay for that luxury. Reading these descriptions from the article, I can't help drawi…

https://news.ycombinator.com/item?id=23826376

Re: An oral history of Bank Python

#159

Post by pantsforbirds »

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…

I think part of the problem with Excel (or clones) is that you can do so much haha. Its such a powerful tool, that you end up doing things in it that it really wasn't optimized or designed for and managing the change history in excel is pretty tough.

But for 95%+ of analysis you really cant beat it.

Re: An oral history of Bank Python

#160

Post by qwhelan »

hdjjhhvvhga wrote: post #114
JoshTriplett wrote: post #80

Earlier quoted context omitted.

There are a number of workplaces where I'd have been willing to rely on "probably wouldn't be fired", but a bank is definitely not one of them. Congratulations on shipping something useful in the face of that risk and uncertainty.

> but a bank is definitely not one of them Investment banks are basically risk-management shops. The partner made an assessment and evaluated the potential benefits as higher than risks. Note the word "probably".

Also worth mentioning that "unapproved software" on bank infrastructure is what an aggressive prosecutor would call "felony bank hacking".
Post reply on HN