7 ms·

Did anyone else notice that the biggest non-academic supporters of functional programming seem to be financial institutions? Is it due to the nature of the pro

by scribu 6y ago

Did anyone else notice that the biggest non-academic supporters of functional programming seem to be financial institutions? Is it due to the nature of the problem space? Is it because finance people tend to be more analytical? Something else?

gphil 6y ago
I think the answer to both of your questions is yes. I think the related concepts of immutability and pure functions without mutable state allow for cleaner analytical modeling (and in some cases in strong functional languages, mathematical proof) of what that the code is actually going to do in production. That kind of predictability is essential for dealing with financial computations.
nolok 6y ago
I would assume it's because it's easier to provide a mathemathical proof for the code with functionnal programming.
Joe8Bit 6y ago
Immutability is a very powerful idea when record keeping and dealing with transactions. I know of at least one major bank whose ledgers are written Haskell.
- bhurlow 6y ago
  any relevant links to share about this?
  - mark_l_watson 6y ago
    Perhaps: Standard Chartered Singapore? I tried unsuccessfully to get a job with them about 4-5 years ago. They are a huge Haskell shop.
    - davidrupp 6y ago
      Sounds like a broken hiring process right there. Anything you care to share about why that didn't work out? I can't imagine a company having an opportunity to hire you and choosing not to.
      - mark_l_watson 6y ago
        I don't mind sharing about that. Standard Charter has the reputation for being a great Haskell shop and I have been trying for years to up my Haskell skills. I simply didn't have enough background in Haskell. The interview was fun. The interviewer did his PhD in Haskell and compiler theory. Around the same time, I applied to Facebook's Haskell group, and I got to interview with Simon Marlow, which was great. He also said that I didn't have enough Haskell experience and suggested that I do more Haskell consulting work, and re-apply in a year. Anyway, I love coding in Haskell but my skills need improvement.
  - niclo 6y ago
    It's Walmart and not a financial institution but this is a great talk about immutability applied to the backend services using F#: https://youtu.be/FskIb9SariI https://youtu.be/FskIb9SariI
    - ilikehurdles 6y ago
      Coincidentally, Walmart also maintains a lot of clojure libraries now, including the go-to graphql implementation in clojure: https://github.com/walmartlabs/lacinia https://github.com/walmartlabs/lacinia
dgb23 6y ago
Functional languages and databases seem to be a natural fit. Given you have a basic grasp of bookkeeping, accounting and financial statements: Would you rather program these things in a functional or imperative language? Would you rather store the transactions in a accreting, value oriented database or one that has no inherent notion of these concepts? Or more generally, if your application has a temporal reporting feature, then you need to be able to ask questions like: "What were these values at date X and what are they going to be at Y?" etc.
orolle 6y ago
It is nature of the problem space which requires you to produce high quality code. If you have a small error in your program, the financial market participants will use it against you to profit. What you loose, others win! Google "fat finger" for examples. In banking you have to keep track of every transactions, see "double accounting". You never delete a transaction, you only retract! Mutablity can cause you a lot of trouble there. SQL DELETE and UPDATE are extremly dangerous! Clojure and datomic solves this through immutibilty. Lastly time is relativistic, meaning that every IT system has a slightly different time. Normaly you never notice this. But they are the cause of tricky race conditions and cost you real money. Think about bank transactions, where you have a transaction date (date you send money) and valuta date (date your friend receives money). One transaction 2 different dates, depending which perspective you take (perspective is relativistic, Einstein is right even in IT!). Datomic linerialies transactions thus this problem does not occure on database level.
- hk__2 6y ago
  > It is nature of the problem space which requires you to produce high quality code. Wouldn’t a strongly-typed language be a better choice here?
  - in9 6y ago
    I wouldn't think that strong types are an advantage. They may be in classic software with long compile times and complex builds. However, the current landscape for financial institution doesn't require that. Immutability and functional paradigms seem to be much more in line with the needs of the business.
  - orolle 6y ago
    I do not think so. The regulation is constantly changing and the meaning of names change frequently. Thus a "Verified Account" can mean different things over the years. The problem with types and object orientation is, that the names used in the domain diverge from the name used in source code (class name, types). Think about a class diagram with class names relating to each other. To represent the domain language better, you need to change a lot in a class diagram. Dynamic languages reduce the problem, as a lot less names are needed. Clojure spec is used for specification of data instead of types, but there is also clojure typed (which uses javas type system).
dig1 6y ago
Mainly because of the problem space. Banking/finance is a complex field with many moving parts: card processing, validation, encryption, currency exchange and tons of certification stuff (I believe Nubank's primary focus is card processing). Didn't even touch other financial fields like investing, credit handling, or any kind of trading. The software is always expected to be correct, never fail and fast. Otherwise, someone will lose the money, and usually, you (bank or institution) will have to recoup that, plus penalties, plus name damage. Source: worked there.
- darthrupert 6y ago
  Doesn’t banking actually use double accounting to ensure not losing money instead of relying on something as brittle as software? Then again, Wirecard happened. But perhaps that wasn’t exactly banking.
pea 6y ago
In haskell, a lot of the uptake in financial services is because they are writing internal DSLs to do things like modelling exotic options.
dwwoelfel 6y ago
As a counter example, Stripe uses Ruby and Mongo.
Ericson2314 6y ago
Never discount networking effects. I think it's good for the problem, but better languages are better for all problems, so that doesn't explain it enough. Considering that finance is decently geographically distributed, I'd say it's more SV has become javascript hell than finance is especially FP oriented.
dan-robertson 6y ago
I think the best argument is that there are a lot of small financial institutions (small referring mainly to the tech groups at them, that is, so you might hear that some big bank uses eg Haskell but really it’s just some group within their IB arm. I’m sure google has some Haskell around too), and often the kind of people they employ tend to like weird languages. Plenty of financial institutions use lots of c++ or java and plenty use cobol too.

by scribu 6y ago

gphil 6y ago

I think the answer to both of your questions is yes. I think the related concepts of immutability and pure functions without mutable state allow for cleaner analytical modeling (and in some cases in strong functional languages, mathematical proof) of what that the code is actually going to do in production. That kind of predictability is essential for dealing with financial computations.

nolok 6y ago

I would assume it's because it's easier to provide a mathemathical proof for the code with functionnal programming.

Joe8Bit 6y ago

Immutability is a very powerful idea when record keeping and dealing with transactions. I know of at least one major bank whose ledgers are written Haskell.

bhurlow 6y ago
any relevant links to share about this?
- mark_l_watson 6y ago
  Perhaps: Standard Chartered Singapore? I tried unsuccessfully to get a job with them about 4-5 years ago. They are a huge Haskell shop.
  - davidrupp 6y ago
    Sounds like a broken hiring process right there. Anything you care to share about why that didn't work out? I can't imagine a company having an opportunity to hire you and choosing not to.
    - mark_l_watson 6y ago
      I don't mind sharing about that. Standard Charter has the reputation for being a great Haskell shop and I have been trying for years to up my Haskell skills. I simply didn't have enough background in Haskell. The interview was fun. The interviewer did his PhD in Haskell and compiler theory. Around the same time, I applied to Facebook's Haskell group, and I got to interview with Simon Marlow, which was great. He also said that I didn't have enough Haskell experience and suggested that I do more Haskell consulting work, and re-apply in a year. Anyway, I love coding in Haskell but my skills need improvement.
- niclo 6y ago
  It's Walmart and not a financial institution but this is a great talk about immutability applied to the backend services using F#: https://youtu.be/FskIb9SariI https://youtu.be/FskIb9SariI
  - ilikehurdles 6y ago
    Coincidentally, Walmart also maintains a lot of clojure libraries now, including the go-to graphql implementation in clojure: https://github.com/walmartlabs/lacinia https://github.com/walmartlabs/lacinia

dgb23 6y ago

Functional languages and databases seem to be a natural fit. Given you have a basic grasp of bookkeeping, accounting and financial statements: Would you rather program these things in a functional or imperative language? Would you rather store the transactions in a accreting, value oriented database or one that has no inherent notion of these concepts? Or more generally, if your application has a temporal reporting feature, then you need to be able to ask questions like: "What were these values at date X and what are they going to be at Y?" etc.

orolle 6y ago

It is nature of the problem space which requires you to produce high quality code. If you have a small error in your program, the financial market participants will use it against you to profit. What you loose, others win! Google "fat finger" for examples. In banking you have to keep track of every transactions, see "double accounting". You never delete a transaction, you only retract! Mutablity can cause you a lot of trouble there. SQL DELETE and UPDATE are extremly dangerous! Clojure and datomic solves this through immutibilty. Lastly time is relativistic, meaning that every IT system has a slightly different time. Normaly you never notice this. But they are the cause of tricky race conditions and cost you real money. Think about bank transactions, where you have a transaction date (date you send money) and valuta date (date your friend receives money). One transaction 2 different dates, depending which perspective you take (perspective is relativistic, Einstein is right even in IT!). Datomic linerialies transactions thus this problem does not occure on database level.

hk__2 6y ago
> It is nature of the problem space which requires you to produce high quality code. Wouldn’t a strongly-typed language be a better choice here?
- in9 6y ago
  I wouldn't think that strong types are an advantage. They may be in classic software with long compile times and complex builds. However, the current landscape for financial institution doesn't require that. Immutability and functional paradigms seem to be much more in line with the needs of the business.
- orolle 6y ago
  I do not think so. The regulation is constantly changing and the meaning of names change frequently. Thus a "Verified Account" can mean different things over the years. The problem with types and object orientation is, that the names used in the domain diverge from the name used in source code (class name, types). Think about a class diagram with class names relating to each other. To represent the domain language better, you need to change a lot in a class diagram. Dynamic languages reduce the problem, as a lot less names are needed. Clojure spec is used for specification of data instead of types, but there is also clojure typed (which uses javas type system).

dig1 6y ago

Mainly because of the problem space. Banking/finance is a complex field with many moving parts: card processing, validation, encryption, currency exchange and tons of certification stuff (I believe Nubank's primary focus is card processing). Didn't even touch other financial fields like investing, credit handling, or any kind of trading. The software is always expected to be correct, never fail and fast. Otherwise, someone will lose the money, and usually, you (bank or institution) will have to recoup that, plus penalties, plus name damage. Source: worked there.

darthrupert 6y ago
Doesn’t banking actually use double accounting to ensure not losing money instead of relying on something as brittle as software? Then again, Wirecard happened. But perhaps that wasn’t exactly banking.

pea 6y ago

In haskell, a lot of the uptake in financial services is because they are writing internal DSLs to do things like modelling exotic options.

dwwoelfel 6y ago

As a counter example, Stripe uses Ruby and Mongo.

Ericson2314 6y ago

Never discount networking effects. I think it's good for the problem, but better languages are better for all problems, so that doesn't explain it enough. Considering that finance is decently geographically distributed, I'd say it's more SV has become javascript hell than finance is especially FP oriented.

dan-robertson 6y ago

I think the best argument is that there are a lot of small financial institutions (small referring mainly to the tech groups at them, that is, so you might hear that some big bank uses eg Haskell but really it’s just some group within their IB arm. I’m sure google has some Haskell around too), and often the kind of people they employ tend to like weird languages. Plenty of financial institutions use lots of c++ or java and plenty use cobol too.