5 ms·

> Are banks still using Perl in 2020? The correct answer is no. > There is no more Perl at JP Morgan, the largest investment bank in the US. The last Perl code

by lol768 6y ago

> Are banks still using Perl in 2020? The correct answer is no. > There is no more Perl at JP Morgan, the largest investment bank in the US. The last Perl code was decommissioned in 2019. I see the situation at JP Morgan now extrapolates to all banks globally. I am glad that JP have done something sensible here, though. > Nope, not python 3. Think 2018-2019 so no python 3 in sight. What. That was literally last year. We all knew Python 2.7 was going to be EOL on January 1st 2020. I know a lot of these legacy banks/financial institutions seem to operate in a time-shifted bubble a good few decades in the past, so maybe that explains it?

x87678r 6y ago
I know right. Banks are so risk adverse now, the biggest thing people are worried about is breaking things and downtime. Running on 10 year old platforms isn't a problem as long as there is no outage. No wonder they're getting killed by Citadel.
- lol768 6y ago
  > I know right. Banks are so risk adverse now, the biggest thing people are worried about is breaking things and downtime. Yeah, it's funny though that the ones who've stuck to their aging mainframe systems and haven't invested in maintenance and reducing technical debt have the worst uptime. https://github.com/openbankingspace/tpp-issues/issues?q=is%3Aissue https://github.com/openbankingspace/tpp-issues/issues?q=is%3... https://twitter.com/nickrw/status/1141058572547215360 https://twitter.com/nickrw/status/1141058572547215360 https://twitter.com/kieranmch/status/1188118150757224449 https://twitter.com/kieranmch/status/1188118150757224449 It's okay though, because they generally don't even tell the customers when it's broken. I get status updates, good quality technical post-mortems and generally very good uptime from my modern bank.
- elcomet 6y ago
  But there's a reason for this. No one wants to be unable to pay for something when they really need it (gas,.. ). So downtime for banks is very bad for business and for people's lives.
- derriz 6y ago
  No bank is getting killed by Citadel. The numbers are on a different scale completely. JP Morgan makes over $40B a year. The entire proprietary HFT industry globally makes a fraction of that. Citadel almost certainly less than 5% of that number in a typical year.
chrisseaton 6y ago
> We all knew Python 2.7 was going to be EOL on January 1st 2020. Note that this just means that the Python people won't support Python 2.7 going forward. I think you will be able to get Python 2.7 support if you pay for it for perhaps literally the next hundred years.
- deleted 6y ago
  [deleted]
Tade0 6y ago
I know a lot of these legacy banks/financial institutions seem to operate in a time-shifted bubble a good few decades in the past, so maybe that explains it? Decades maybe not necessarily, but years definitely. It boils down to the very real risk of being sued for damages if something's wrong with a payment. I'm currently in a project which aims to re-write the front-end of a library of banking components - from AngularJS to Angular 9. The product is fairly simple to use, but still it's being delivered a year before AngularJS's end-of-life which will be after the 30th June 2021, because the time window for ensuring this thing works according to the banks' use cases must be as wide as possible.
- lol768 6y ago
  > I'm currently in a project which aims to re-write the front-end of a library of banking components - from AngularJS to Angular 9. The product is fairly simple to use, but still it's being delivered a year before AngularJS's end-of-life which will be after the 30th June 2021, because the time window for ensuring this thing works according to the banks' use cases must be as wide as possible. Is this in the states? I get the impression the regulatory landscape is much more hostile to innovation and tends to favour incumbents (vs the UK, recently, where challengers have been supported a bit more).
  - Tade0 6y ago
    Nope, the company itself is based in Switzerland.
- smoe 6y ago
  In general i think it is fine that banks and similar places are years behind. It is not exaclty the kind of institutions i want to mess around with bleeding edge, barely tested and undocumented technogy.(not referring to Angular here) The problem that I have seen in the enterprise/goverment world when I was in it, is them not keeping up from behind. E.g. They might be reasoanbly recent for a new project, but then dont update for a decade or so. There is this recent introductory talk about enterprise frontend stacks on why it makes sense for them to stay quite far behind (compared to the pace in frontend dev) the latest developments that I found pretty interesting. https://www.infoq.com/news/2020/06/second-generation-js-frameworks/ https://www.infoq.com/news/2020/06/second-generation-js-fram...
onei 6y ago
It's not even python2.7, they went with 2.6. A version that reached end of official support in 2013. All because that's the default for RHEL 6. It's not hard to build RPMs of newer and/or supported versions of Python. You might even find it in EPEL. I get being risk averse, but if you're going to make the change, move to something sensible that your developers will want to work with.
- throwaway8941 6y ago
  No need to build anything. https://www.softwarecollections.org/en/ https://www.softwarecollections.org/en/
- ChrisSD 6y ago
  On the other hand Python 2.6 will be supported on RHEL 6 for as long as RHEL 6 is supported. Of course this still means having to switch again in a few years time but that's a problem for future JP Morgan.
  - bdavis__ 6y ago
    Centos6 goes out of support this year.
    - ChrisSD 6y ago
      Sure but RHEL 6 has Extended Life-cycle Support until 2024.
  - tyingq 6y ago
    RHEL 6 EOL is 11/30/2020. There's "extended support", but no patches, not even security patches. Edit: Apparently I was wrong about some security patches, but ELS sounds complicated: https://access.redhat.com/discussions/2399461 https://access.redhat.com/discussions/2399461
    - ChrisSD 6y ago
      It sounds like you can pay extra for security patches until 2024: https://access.redhat.com/support/policy/updates/errata/#Extended_Life_Cycle_Support https://access.redhat.com/support/policy/updates/errata/#Ext...
mcv 6y ago
Yeah, JP Morgan doesn't use Perl, so nobody uses Perl? I would not take that bet. None of the banks I worked for uses Perl to my knowledge, but that doesn't mean they don't use Perl at all, and certainly not that no other bank uses Perl. But is there a problem if banks use Perl specifically? I'm no Perl fan, and I certainly wouldn't use Perl (or Python or NodeJS for that matter) to run systems handling money, but there's a lot more than just direct money handling going on at banks.
craigsmansion 6y ago
> I am glad that JP have done something sensible here, I doubt that. For over 20 years people have been pinning their hopes on new languages and "paradigms" to make things better. Things haven't progressed a lot with that strategy. I blame this on how software architects don't, and programmers can't, and because of that they all hedge their bets on new language X with feature Y, hoping it will make all the hard bits go away. It's akin to how in the creative writing world, writers sometimes dive deep into the grammar and vocabulary of a particular natural language whereas the real challenge is thinking up new and entertaining situations and characters, and then filling that in with words in whatever language you happen to be proficient in. Literate programming has been a concept for a long time now: write a document that explains, understandably, what the software is supposed to do, then accompany it with some source in whatever language the programmer is most comfortable with. In a perfect world, that would be called "doing you job". In our current world, there is no money to be made in "doing your job" and it will be heckled as slow or outdated; praying for deliverance is much more profitable. The too long, didn't read: Turing and Church proved that, fundamentally, all languages suck, so no new language will ever save one from one's own incompetence. Maybe it's time we all stopped blaming or praising "the language" wholesale for the various inadequacies and blind spots in our branch of industry.
- continuational 6y ago
  Do you prefer Brainfuck? No? Then you can probably see the flaw in your own argument.

by lol768 6y ago

x87678r 6y ago

I know right. Banks are so risk adverse now, the biggest thing people are worried about is breaking things and downtime. Running on 10 year old platforms isn't a problem as long as there is no outage. No wonder they're getting killed by Citadel.

lol768 6y ago
> I know right. Banks are so risk adverse now, the biggest thing people are worried about is breaking things and downtime. Yeah, it's funny though that the ones who've stuck to their aging mainframe systems and haven't invested in maintenance and reducing technical debt have the worst uptime. https://github.com/openbankingspace/tpp-issues/issues?q=is%3Aissue https://github.com/openbankingspace/tpp-issues/issues?q=is%3... https://twitter.com/nickrw/status/1141058572547215360 https://twitter.com/nickrw/status/1141058572547215360 https://twitter.com/kieranmch/status/1188118150757224449 https://twitter.com/kieranmch/status/1188118150757224449 It's okay though, because they generally don't even tell the customers when it's broken. I get status updates, good quality technical post-mortems and generally very good uptime from my modern bank.
elcomet 6y ago
But there's a reason for this. No one wants to be unable to pay for something when they really need it (gas,.. ). So downtime for banks is very bad for business and for people's lives.
derriz 6y ago
No bank is getting killed by Citadel. The numbers are on a different scale completely. JP Morgan makes over $40B a year. The entire proprietary HFT industry globally makes a fraction of that. Citadel almost certainly less than 5% of that number in a typical year.

chrisseaton 6y ago

> We all knew Python 2.7 was going to be EOL on January 1st 2020. Note that this just means that the Python people won't support Python 2.7 going forward. I think you will be able to get Python 2.7 support if you pay for it for perhaps literally the next hundred years.

deleted 6y ago
[deleted]

Tade0 6y ago

I know a lot of these legacy banks/financial institutions seem to operate in a time-shifted bubble a good few decades in the past, so maybe that explains it? Decades maybe not necessarily, but years definitely. It boils down to the very real risk of being sued for damages if something's wrong with a payment. I'm currently in a project which aims to re-write the front-end of a library of banking components - from AngularJS to Angular 9. The product is fairly simple to use, but still it's being delivered a year before AngularJS's end-of-life which will be after the 30th June 2021, because the time window for ensuring this thing works according to the banks' use cases must be as wide as possible.

lol768 6y ago
> I'm currently in a project which aims to re-write the front-end of a library of banking components - from AngularJS to Angular 9. The product is fairly simple to use, but still it's being delivered a year before AngularJS's end-of-life which will be after the 30th June 2021, because the time window for ensuring this thing works according to the banks' use cases must be as wide as possible. Is this in the states? I get the impression the regulatory landscape is much more hostile to innovation and tends to favour incumbents (vs the UK, recently, where challengers have been supported a bit more).
- Tade0 6y ago
  Nope, the company itself is based in Switzerland.
smoe 6y ago
In general i think it is fine that banks and similar places are years behind. It is not exaclty the kind of institutions i want to mess around with bleeding edge, barely tested and undocumented technogy.(not referring to Angular here) The problem that I have seen in the enterprise/goverment world when I was in it, is them not keeping up from behind. E.g. They might be reasoanbly recent for a new project, but then dont update for a decade or so. There is this recent introductory talk about enterprise frontend stacks on why it makes sense for them to stay quite far behind (compared to the pace in frontend dev) the latest developments that I found pretty interesting. https://www.infoq.com/news/2020/06/second-generation-js-frameworks/ https://www.infoq.com/news/2020/06/second-generation-js-fram...

onei 6y ago

It's not even python2.7, they went with 2.6. A version that reached end of official support in 2013. All because that's the default for RHEL 6. It's not hard to build RPMs of newer and/or supported versions of Python. You might even find it in EPEL. I get being risk averse, but if you're going to make the change, move to something sensible that your developers will want to work with.

throwaway8941 6y ago
No need to build anything. https://www.softwarecollections.org/en/ https://www.softwarecollections.org/en/
ChrisSD 6y ago
On the other hand Python 2.6 will be supported on RHEL 6 for as long as RHEL 6 is supported. Of course this still means having to switch again in a few years time but that's a problem for future JP Morgan.
- bdavis__ 6y ago
  Centos6 goes out of support this year.
  - ChrisSD 6y ago
    Sure but RHEL 6 has Extended Life-cycle Support until 2024.
- tyingq 6y ago
  RHEL 6 EOL is 11/30/2020. There's "extended support", but no patches, not even security patches. Edit: Apparently I was wrong about some security patches, but ELS sounds complicated: https://access.redhat.com/discussions/2399461 https://access.redhat.com/discussions/2399461
  - ChrisSD 6y ago
    It sounds like you can pay extra for security patches until 2024: https://access.redhat.com/support/policy/updates/errata/#Extended_Life_Cycle_Support https://access.redhat.com/support/policy/updates/errata/#Ext...

mcv 6y ago

Yeah, JP Morgan doesn't use Perl, so nobody uses Perl? I would not take that bet. None of the banks I worked for uses Perl to my knowledge, but that doesn't mean they don't use Perl at all, and certainly not that no other bank uses Perl. But is there a problem if banks use Perl specifically? I'm no Perl fan, and I certainly wouldn't use Perl (or Python or NodeJS for that matter) to run systems handling money, but there's a lot more than just direct money handling going on at banks.

craigsmansion 6y ago

> I am glad that JP have done something sensible here, I doubt that. For over 20 years people have been pinning their hopes on new languages and "paradigms" to make things better. Things haven't progressed a lot with that strategy. I blame this on how software architects don't, and programmers can't, and because of that they all hedge their bets on new language X with feature Y, hoping it will make all the hard bits go away. It's akin to how in the creative writing world, writers sometimes dive deep into the grammar and vocabulary of a particular natural language whereas the real challenge is thinking up new and entertaining situations and characters, and then filling that in with words in whatever language you happen to be proficient in. Literate programming has been a concept for a long time now: write a document that explains, understandably, what the software is supposed to do, then accompany it with some source in whatever language the programmer is most comfortable with. In a perfect world, that would be called "doing you job". In our current world, there is no money to be made in "doing your job" and it will be heckled as slow or outdated; praying for deliverance is much more profitable. The too long, didn't read: Turing and Church proved that, fundamentally, all languages suck, so no new language will ever save one from one's own incompetence. Maybe it's time we all stopped blaming or praising "the language" wholesale for the various inadequacies and blind spots in our branch of industry.

continuational 6y ago
Do you prefer Brainfuck? No? Then you can probably see the flaw in your own argument.